Raible Designs

The cost of bandwidth

My ISP, KGB Internet Solutions sent me a bill today - it's usually pretty cheap at $12 US per month. However, this month, they charged me an additional $28 for 3 gigs of extra bandwidth - Yikes! I'd better quit posting things for downloads eh? Should I make attempts to reduce my traffic. Nahh, I'll pass - I'll just buy more bandwidth! Keep the hits coming - I feel the love! I think I'll upgrade to their Silver package ($20 US) which has 5 GB of monthly transfer. It looks like it comes with a 100MB connection, which I thought I already had - but maybe not. I hope not, it'd be sweet to upgrade to a better package and get faster speeds too.

I also found this Servlet ISP list at servlets.com. Looks like KGB Internet got a 4.9 out of 5, and Dave's ISP (Kattare) got a 4.8 - obviously both great choices.

Getting this bill was quite humorous since Dave send me an e-mail this morning. In his e-mail, he suggested that I add a donate (via PayPal) button to my site. Good idea, but I don't think anyone would use it, and I hate to put off my readers. I'm thinking of donating to Dave for his great product, and also to FreeRoller for its great content.

JavaBlogs Outage

It's no fun to work all day on a Saturday. It's even less fun when java.blogs is out of commission. I did a little research and while atlassian.com is still up, most of the JIRA instances for open source projects (i.e. Roller, XDoclet) is down. It appears (via ping-analysis) that the OSS JIRA instances are hosted on the same server as java.blogs. Since I'm getting a ping reply from this server, I'm assuming the servlet container is down and everyone in AUS is partying it up all weekend. I hope it's fixed when they get back to the office on Monday. That's Sunday for us right?

Hibernate Workarounds

Gavin King has started a new Wiki page for Hibernate users. Contribute if you've got some Hibernate knowledge. I hope to add value in the next month or two, or possible get value from this. Gavin hooked me up today with a 2nd set of eyes on a Hibernate -> Oracle issue I was having. User error - of course!

I have started a new Wiki page in the community area where we can (collaboratively) produce some documentation of common Hibernate design patterns. The page is called "workarounds" at the moment, but it can be more general than that. I've documented two patterns already and added one TODO (for people with knowledge of Maverick / servlet filters to fill out).

Design Patterns, Marc Fleury and JBoss

I just got back from the Denver JUG meeting and have lots to talk about. I've started this post at 11:03 p.m., for the record. I want to start out with discusssing a topic that Dave and I talked about a few days ago. Basically, in his Ag application, he is using one Business Delegate and one DAO to do all his business logic and data access. Actually, he's got two DAO's, one for Hibernate and one for Castor. Basically, the DAO is determined at startup, set on the Business Delegate and then stuffed into the servlet context. While Ag is a small application, it got me thinking. I believe the recommended pattern for this is to have a Business Delegate for each entity, as well as a DAO. So for a user, you would end up with 4 classes, UserManager/UserManagerImpl and UserDAO/UserDAOHibernate. So everytime I add a new entity, i.e. account, I have to create 4 new classes. What a pain, and a lot of copy and pasting - or at least that's how I'd do it.

Dave's KISS methodology at first struck me as strange, but then I thought, "Damn, that's a lot easier." So now in AppFuse (reference implementation: security-example), I changed to use this idea - with a BusinessManager/BusinessManagerImpl and ApplicationDAO/ApplicationDAOImpl. The idea is that these will contain any and all methods to access data.

I went to the DJUG meeting still struggling this this pattern, feeling like it stunk and I should back it out and go with a factory pattern and a business delegate/dao for each entity. However, during Marc Fleury's presentation, he preached that one of the founding rules of JBoss was KISS. He said that the greatest thing about open source is that no one will ever even look at your code until it's broken. "And how bad does it suck when you have to look through 5 levels of inheritence to figure out the problem?" He mentioned that bad code was his favorite, because chances are - if there's a bug - it'll be staring you in the face, rather than buried inside some design patterns and 10 different classes. I agree, so I'm going with KISS, but I'm also interested in hearing your opinions. I like the current architecture of AppFuse because it sets the business manager on startup, stores it in the servlet context and is available for everyone to use at any time. There's nothing saying that I couldn't set a SessionBean (on the business manager as it's proxy) and call EJBs for my persistence layer.

In fact, after Marc's gospel about JBoss, I want to use EJBs. In fact, not just EJBs, I want to use JBoss - and I can't wait for "JB 4." Why? Well they're adding the ability to add all of EJB's services (i.e. Security, Transactions, Persistence) to any POJO. This means that all you need to do is write a little deployment descriptor for it, and whalla, you're in business. His sermon is something you really need to see to appreciate. I can't do it justice in summarizing it here, but I certainly liked what he had to say, and feel like I'm a better person for it. The JBoss Group's goal is to become the de facto standard for application servers. I like their idea that the app server should be free - and the money (usually spent on app servers) should be directed towards smart developers instead. He also mentioned that JBoss Group (the company) is doing great right now and will be spending some cash on Marketing and PR to squash any rumors that it's not good enough.

Marc mentioned that most of the things he talked about tonight are written in his Blue Paper (PDF, 11 pages), titled "Why I love EJBs". It's part 1 of 3, the Blue of the "Red, White and Blue Technology Trilogy."

Other news that I stumbled upon today:

• JBoss uses JavaGroups, and I've heard you can make work with Tomcat - for clustering and such.
• The release plan for Struts 1.1 Beta 3 has been committed to CVS, code freeze this Saturday.
• Ted Husted defends Struts after I posted it's recent criticizm to the mailing list.
• The xPetstore Application has a new release. xPetStore is a refactored version of Sun PetStore application that shows how to use xDoclet to build WODRA (Write Once, Deploy and Run Anywhere) J2EE application. Tested with JBoss and WebLogic.

Phew, done at 11:44 p.m.

Webapp Configuration

Jeff Duska has a post tonight on how he handles app-specific configuration settings. His method sounds pretty neat, and hopefully we can combine our methods to come up with a better solution. Here's how I've been doing it.

1. I have a StartupServlet that reads in an XML file and, using Castor, populates a JavaBean with the XML file's values. Sidenote - I recommend having a StartupServlet in webapps to populate drop-down choices from the database and stuff ArrayLists (of beans) into the ServletContext - works real slick in Struts using the LabelValueBean.
2. Stuff the JavaBean into the servlet context and get values as needed while running the app.

Jeff's method seems make it easier to retrieve the values, but not to set them. I have a getConfiguration() method in my BaseAction class that I use to get my configuration data:

/**
 * Get the Configuration object from the servlet context
 */
public Configuration getConfiguration(){
    return (Configuration) servlet.getServletContext().getAttribute(
                   Constants.CONFIGURATION);
}

The obvious problem with this is that only subclasses of BaseAction can get the configuration information - therefore, I like Jeff's idea better. However, I'm curious to know how he populates his Registry class. Castor makes it pretty damn easy. Here's the method I use in StartupServlet, where obj is my JavaBean, and xmlFilePath is configured as "/WEB-INF/app-config.xml" in one of StartupServlet's init-parameters.

/**
 * Load our application configuration XML file.
 *
 * @exception Exception if any problem occurs while loading
 */
private synchronized Object loadConfig 
    (
    Object obj, 
    String xmlFilePath
    ) 
throws Exception {

    // attempt to extract the filename, using system file separator
    int index = xmlFilePath.lastIndexOf(Constants.FILE_SEP);

    // no system file separator found in configuration setting
    if (index == -1) {
        // check traditional file separator as used in web app URI's
        index = xmlFilePath.lastIndexOf("/");
        // still no separator, maybe they're just specifying the filename
        if (index == -1) {
            index = 0;
        }
    }

    String xmlFileName = 
        xmlFilePath.substring(index + 1, xmlFilePath.length());
    if (logger.isDebugEnabled()) {
        logger.debug("Looking for '" + xmlFileName + "' in "
                 + Constants.USER_HOME);
    }

    // Acquire an input stream to our configuration file
    InputStream is = null;
    try {
        is = new FileInputStream(Constants.USER_HOME + xmlFileName);
    } catch (FileNotFoundException fnf) {
    
        // No file found in user.home
        if (logger.isDebugEnabled()) {
            logger.debug("File not found at " + Constants.USER_HOME
                + xmlFileName + " - looking at specified path in web.xml.");
        }
        
        // Look for config.xml in WEB-INF
        is = getServletContext().getResourceAsStream(xmlFilePath);
        if (is == null) {
            throw new Exception("Configuration file '"
                + xmlFileName + "' not found in '"
                + Constants.USER_HOME + "', nor at '" + xmlFilePath + "'");
        }
    }

    InputStreamReader reader = new InputStreamReader(is);
    
    // Marshal the configuration object
    obj = Unmarshaller.unmarshal(obj.getClass(), reader);

    // close the InputStream, and the reader
    is.close();
    reader.close();
       
    return obj;
}

I like this method because it can load multiple configuration files, and I already have it written - so the hard part is over ;-) It also makes it easy to configure your app outside of WEB-INF, and changes won't be overwritten when a user upgrades their WAR file or whatnot. I suppose I could use Jeff's method and make my JavaBean into a Singleton and not store it in ServletContext - that'll probably work better than my current scenario.

Using one JSP for form-based authentication

I'm writing about how to use the same login/error page with form-based authentication. Does anyone know which servlet containers this fails on? I guess it wouldn't hurt to know which ones it works on too. You can use this security.war (1.7MB) file to test. Since it's testing the failure page, you don't need to setup a user - but if you want, the role is tomcat. I know this works on Tomcat, so no need to test it.

Using JAAS and making it switchable

Erik Hatcher has convinced me that I need to give more coverage to JAAS in my chapter on Security. To quote his comment from yesterday's JAAS post:

I think you are underestimating the value of JAAS a fair bit. Suppose you want to authenticate your users against a database table of users/passwords. Without JAAS this is container-specific (sure it works nice in Tomcat, but would you be able to do FORM authentication in WebSphere easily?). We use JAAS in the big application I'm developing and it gives us the freedom to more easily port our application to other containers. What if your application needed to authenticate users (suppose for a portal, not that far fetched, eh?) where each "portlet" had a different authentication scheme: LDAP, Windows NT, database, etc. JAAS is the way to go.

While I can see Erik's point, I think that if the app servers follow the Servlet spec, implementing form-based authentication on any J2EE-compliant server should be easy. After all, Tomcat is the Reference Implementation. At the same time, the bit about the portles is a whole other can of worms - I can see what he's getting at, and I guess I need to figure out an easy way to demonstrate using JAAS. From what I understand, you do have to call the authenticate() in a servlet or filter. Hopefully, I can use a little Ant/XDoclet magic to create a sample that can switch b/w form-based, container-managed authentication and JAAS. Tell me what you think of this idea:

• Use Ant and a task that runs if ${enable.jaas} is true
• This task (i.e. jaas) will add a JAAS policy file to the webapp, maybe in the WEB-INF/classes directory so it's in the classpath
• The jaas task will do some token replacement in login.jsp to change the form's action from j_security_check to something else. Ideally, I wouldn't have to do this.
• The webdoclet task with not merge the web-security.xml file into web.xml
• The ActionFilter, which I currently use to retrieve the user's information, will call the authenticate method and route appropriately if JAAS is enabled.

One thing I really like about form-based authentication (besides the ease of setup and no required programming) is that it allows users to bookmark pages in your app. When they select that bookmark again after logging out, they are prompted for a login and routed to the bookmark upon successful authentication. I hope JAAS can do this too.

JSP 2.0 and Servlets 2.4 Research

I'm going to record a few items from my JSP 2.0 and Servlet 2.4 research tonight. I hope you don't mind.

From JSR 152 (JSP 2.0):

We plan to incorporate two main new features into JSP, and a few incremental features. Additionally we expect to incorporate erratas and clarifications as well as opportunistic improvements.

The two key features are the use of JSP to author custom actions, and adding expression language support into the container. The main goal of this JSR is to deliver these new features into the JSP specification in a timely manner. This goal will likely limit what other features can be incorporated.

So (to me) this means that if you know JSTL, you already know half of JSP 2.0. And the best part of JSP 2.0? One main theme of this update of the JSP specification is that we want to simplify, not complicate, the view of a JSP that most users, specially page authors, have.

From JSR 154 (Servlet 2.4):

Servlet 2.4 will be a relatively small upgrade to the existing API. Since the technology is highly popular, we have a large number of small requests for enhancement to the API that we would like to be able to accommodate. Over and above that, Servlet 2.4 will address the following areas in a portable manner:-

* Modularization of the deployment format

The goal is to achieve a level of modularity with the deployment format which is not currently possible using the current DTD based deployment descriptor. The intent is to enable this modularity to manage the organization of deployment information of related technologies that use the web container as the underlying platform. These frameworks include dependencies on other J2EE components, JSP technology, JavaServer Faces, JAXM, JAX-RPC and other frameworks that build on servlet semantics.

Hmmm, this almost sounds like the module idea in Struts. Does this mean they want to allow sub-applications (or modules) within a web application? After a little research, it appears that the 2.4 spec will allow you to add new namespaces to your web.xml file, and therefore, you can extend the deployment descriptor for your own needs. Look for vendors to use this, as well as UI Frameworks like JSF. The top of your web.xml will resemble the following on 2.4 container:

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://
    java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">

Also on the list:

* Enhancements to the security model
     - Provide a facility for logging out of web applications portably
     - Clarify, possibly by adding API or deployment syntax, the relationship between HTTP session state and authentication state

* Smallish enhancements to the filter and listener models
     - Provision of deployment syntax for declaring API dependencies between elements in a filter chain
     - Addition of request and response level listeners and event notifications.

Cool, sounds like good stuff. Logging out of web applications portably? You mean there's more we can do than invalidate the session? I wonder what else there is to logging out? Maybe it'll remember the last page the user was on? No such luck (but you can do that with Cookies). It appears that there's a strong effort to encourage vendors to implement single sign-on for webapps. Tomcat is the only one I know that does this now. HttpSession has a new logout method - if the servlet container implements single signon, the logout logs the client out of all web applications on the servlet container and invalidates all sessions associated with the same client. I guess this is cool if you have more than one webapp on your server. Now we just need an API to allow webapps to talk to each other on the same container. I guess you could call this HTTP, but I want something better than that. Another interesting item I found is that you'll be able to use a servlet as your welcome-file, which is currently not allowed in the 2.3 spec.

So how do these new specs influence how you write your webapps? It doesn't seem like there's much that's new, and certainly no ground-breaking features. So learn Struts, so you'll have a headstart on JSF, and learn JSTL, so you'll know the expression language used in JSP 2.0. If you've been put off by writing tag libraries, it'll be easier with JSP 2.0, as you'll be able to use JSP fragments as a type of tag library. Lastly, if you're not using container-managed authentication (i.e. BASIC, FORM), you might want to consider it. The thing I like most about container-managed authentication is that you can bookmark pages in an app, and then get right back to them by entering a login/password - this is how it should be vs. login -> main menu -> bookmarked page. You can use filters to restore any session or request information that is needed for the bookmarked page.

Pheww, boy am I lucky! I copy-pasted this post before I tried to submit it, and whaddya know, Chimera crashed after I hit the "Post to Weblog" button!

Using XDoclet on Large Projects

Kurt emerges from his sabbatical (12 days is a long time in blogsphere) and mentions a little tidbit I'd like to comment on:

Last week I attending a TC JUG meeting where the topic was Struts 1.1: The Good, the Bad and the Ugly.
...
Interestingly the speaker didn't like XDoclet because he felt that on large development teams the config files should be managed outside of the source code during the design phase. Since I have never worked on a large team (not that I won't want to) I don't know if his concern is valid. Interesting comment though.

(I added the bold.) First of all, I have only recently (last 6 months) found XDoclet, and all the projects I've been on (in my entire life) have always had less than 5 coders. I've been on teams as large as 20, but the module I was working on never involved everyone. In my experience, the design phase never really consists of writing very much code or configuration, but rather a bunch of UML diagrams and static HTML prototypes.

I have found (in my brief work on struts-xdoclet) that I need to change values in my web.xml to test different settings (i.e. a servlet's init-param). However, since I'm coding some of these values in my classes, in order to change and test, I have to re-compile and deploy. Of course, I could just change the values in web.xml after I've deployed, but that's just a workaround.

A better solution, which I hope to implement, is to put certain values in my classes as tokens (i.e. @encrypt-password@) and then I can use Ant's replace task to specify this value from the command line. That way, I can set the default in my build.xml file and change it by either 1) specifying the property in build.properties, or 2) specifying it from the command line (i.e. ant -Dencrypt-password=true).

I'd be very interested in hearing anyone's war stories on this topic (managing config files in a large team).

Running Tomcat 5

I've gotten a little closer to using and running Tomcat 5. My last post on the subject pointed out an error I received about comments in XML (org.xml.sax.SAXParseException: The string "--" is not permitted within comments). Well, this turned out to be a Xerces issue and has already been reported. So, like a good little programmer, I downloaded the nightly build of Xerces, and replaced xercesImpl.jar and xmlParseAPIs.jar in common/endorsed. Now, I can view the jsp-examples and servlet-examples applications, but I get this error on startup.