Raible Designs

Upgrading Hibernate, Struts and Display Tag

Last night, I upgraded a number of AppFuse dependencies: Hibernate → 2.1-rc, Struts Nightly from 2 weeks ago → Dec. 2nd and the Display Tag → 1.0 B2. The upgrades weren't as smooth as I'm used to, so I thought I'd share my experience to help y'all when you upgrade.

First of all, I found that Hibernate has ditched the Java Caching System (JCS) for their own, appropriately called Easy Hibernate Cache. This means you can forget about including jcs.jar in your webapp, ehcache.jar is now required. I upgraded from Hibernate 2.0.3.

Struts has done some trimming of their own - getting rid of their dependency on commons-lang. I use commons-lang.jar in AppFuse, so I had to dig into the contrib directory and grab it from there.

I had several issues with the displaytag when upgrading (from 0.8.5), but managed to figure them all out. First of all, the displaytag.tld in the jar's META-INF directory had the following in it's <taglib> declaration:

<taglib xmlns:html="http://www.w3.org/1999/xhtml">

This is obviously invalid, and I had to unjar, fix, and re-jar to get around this. I believe that this has been fixed on SF. I also found that this new version requires commons-collections 2.1. Struts must ship with an older version, so I simply replaces Struts' commons-collections with the one from the displaytag download.

The newer commons-collections is around 500 KB smaller - wierd, eh?

Lastly, I had to configure the ResponseOverrideFilter in my web.xml in order to get export functionality with Tiles. I had to tweek a LOT of CSS for this upgrade, but at least it's done now and hopefully I won't have to do it again for quite some time.

I also attempted to run AppFuse (with all these upgrades) in Tomcat 5.0.16 with no luck. With Hibernate 2.0.3, it was giving me an IllegalStateException when registering a new user. This process sets "Remember Me" cookies and redirects to the LoginServlet, which does a post to j_security_check and redirects to the originally requested page. Works fine in Tomcat 4.1.x, but not in 5.0.16. With Hibernate 2.1-rc1, I had to include jta.jar in $CATALINA_HOME/common/lib and now it still fails, but I get no errors whatsoever (those are always fun, aren't they). Also, still no luck with using J2EE 1.4.

DB2 with Hibernate and Tomcat

At my current project, we're using AppFuse for our baseline and (currently) Tomcat and MySQL for our databases. Soon we'll be migrating to DB2 for our database. I'm assuming everything will work smoothly with Hibernate, but there's probably some Ant things I will need to modify. For instance, with MySQL, I currently create a new database with the following script:

create database if not exists appfuse;
grant all privileges on appfuse.* to test@"%" identified by "test";
grant all privileges on appfuse.* to test@localhost identified by "test";

Is this possible with DB2? It's no biggie if it isn't - at my Comcast gig earlier in the year, we tied AppFuse/Hibernate into Oracle and simply didn't use the db-create nor db-init (creates tables) tasks. I use Hibernate's <schemaexport> task to create the tables - hopefully this will work in DB2. As for Tomcat, has anyone successfully configured DB2 with Tomcat's DBCP? We'll eventually be migrating to Websphere 5, hopefully it's not a big leap from Tomcat 4.1.27.

I haven't done any research on this yet, just wanted to put out some feelers and get any helpful advice before I start banging my head against the wall (hopefully I won't have to).

AppFuse 1.0 Released!

I feel this release deserves the big 1.0 designation because it is an up-to-date representation of my learnings and my perceived best practices in building web applications. Of course, as I learn more, I will continue to push out new releases.

In this release, I did a lot of refactoring and enhancements to existing features. The DAO and Manager interfaces are no longer tied to Struts or Hibernate. Hibernate's Session object is now passed as an argument into Manager and DAO constructors, rather than method signatures. The DAOFactory was refactored by Bear Giles to use reflection to instantiate Hibernate DAO's. Now, if you add a new DAO, you don't have to edit DAOFactory and DAOFactoryHibernate. To insantiate a new DAO, the code is now:

LookupDAO dao = (LookupDAO) DAOFactory.getInstance(conn, LookupDAO.class);

...where conn is a connection object retrieved from ServiceLocator or ActionFilter. When you add new POJOs, you still have to add them to ServiceLocator (for JUnit tests) and hibernate.cfg.xml, which is kindof a pain. I'd like to figure out a way to tell Hibernate to just look in appfuse-ejb.jar.

<tangent>
I still don't have a Factory for Managers, and I don't know that there's a need for one, but it's something I might add in the future. Managers are still creating using: LookupManager mgr = new LookupManagerImpl(ActionFilter.getConnection());. One thing I've been thinking about is the ability to switch webapp frameworks - kindof like you can do with Persistence Frameworks and the DAO Pattern. It'd be cool to add a way to switch (at build time) to use WebWork or Tapestry. Maybe by replacing values for the controller in web.xml. It'd probably be a pain since I'd probably have to create new JSPs for the new frameworks - but it would probably be a great learning experience.
</tangent>

The Remember Me feature has been refactored so the username and password cookies are only available under the /appfuse/security url-pattern. I also changed the posting to "j_security_check" in LoginServlet from response.sendRedirect to an HTTP POST, using Jakarta Common's HttpClient. The reason I have a LoginServlet vs. just using action="j_security_check" in my <form> is to encrypt passwords.

I've developed 3 different applications using AppFuse (struts-resume is one of them), and I have found that it's a pain to upgrade to new versions of AppFuse. Because of this, I don't recommend upgrading unless you really need to. I will be upgrading struts-resume to AppFuse 1.0, but I doubt I'll upgrade it to any future AppFuse releases - it's just too much work for not much reward.

• Download (~11.5 MB for src, ~3.9 MB for bin)
• Release Notes
• API Documentation and Source
• Mailing List

AppFuse won't work with J2EE 1.4 Final

I don't know why, but AppFuse's MailUtilTest won't run with J2EE 1.4 Final. It works fine with 1.4 Beta 2.

RE: Compressing and Caching in your webapps

Jayson Falkner writes about two Filters everyone should have in their webapps: one for compression (via gzip) and one for caching. I try to add a CompressionFilter to all the apps I write, but I don't have a CacheFilter. So my question is: should I add Jayson's CacheFilter to AppFuse or should I use OSCache? I haven't got to Dave's chapter yet on performance and caching (in JSP 2.0), so I haven't read his opinion - what's your opinion? I like Jayson's solution because I can add 3 new classses with no additional JARs - AppFuse already has 21 jars (Struts, Hibernate, JSTL + a few other taglibs).

The good ol' Struts vs. WebWork Debate

Jason Carreira has been nice enough to post a technical comparison of Struts vs. WebWork. Don Brown (creator of many Struts add-on packages) and Jason have been going at it ever since. It's funny, there's a small part of me that doesn't believe there's a future for Struts (because of JSF). I believe that JSF and WebWork are quite similar, and if I'm going to take the time to learn a new framework, I should learn JSF. Why? Because, I'm willing to bet the literature for Struts -> JSF is out there, and there's probably no literature for Struts -> WebWork. Also, I believe there will be JSF jobs in the near future, but not many opportunities for WebWork. In a perfect world, I'd do something like Kris is doing and learn them all - extend AppFuse to support my favorite framework (if I find one better than Struts) after the learning process, and use that for new projects.

Where does Kris find the time to learn all these frameworks? I barely have enough time to workout and complete my 8-hours-per-day of productivity-for-pay. Then again, I've been getting up around 7:30-8:00 a lot lately vs. the usual 4 a.m.

In my current gig, I'm teaching a fellow programmer how to write webapps in Java. He's never written Java, HTML, CSS or JavaScript. He wants a tool to do it all - so he can drag-n-drop, point-n-click and voila - he's created a webapp. This is a fundamental problem with J2EE - it's not possible? Or maybe it's the beauty - you have to get down and dirty with the code to create a webapp. Another issue is that we're using Struts Resume as our baseline and architecture - and there's really nothing in this app that's drag-n-drop or tools-friendly. Everything is Ant, JUnit, Struts and Hibernate. You have to be somewhat familiar with all of these to build/deploy this app. Personally, I like getting down-n-dirty with the code, but that's because I'm familiar with it and have been working with it for years. Teaching someone else how to get down-n-dirty (and to like it) is proving to be a whole other battle.

My Development Environment

To make is easier for folks to use AppFuse and Struts Resume, I put together a page for HowTo Configure your Development Environment. This is how I've configured my environment and it works pretty darn well for me. Really, none of the document is AppFuse specific - it just shows where I put J2SE, J2EE, Ant, Tomcat, and how to setup your environment variables. Comments or other suggestions are welcome.

Hibernate 2.1 Beta 5 Released!

Normally I wouldn't announce a Hibernate beta release (since it is a beta and I'm not currently using it), but there's a bunch of bug fixes (see release notes) that folks might be able to use. You can also download this bad-boy if you so desire.

On a side note ~ I find it amusing how my real-world projects influence my open source contributions. I don't follow Hibernate much because I don't use it day to day. On my last few projects, I've used it a lot. When I've used it, I've also used AppFuse, and therefore - I tend to contribute the AppFuse's development more. Same goes for the displaytag - which I haven't used in a project in several months - hence, no code commits from me. The good news is that on my current project, I have been using Struts Menu a LOT and I've committed some wicked new stuff to CVS. I'm busy writing documentation on it now so it will be easier to use for all. Maybe I'll try to convince my next project to use Roller for Project Status Reports...

AppFuse and all it's libraries

I received a question about AppFuse that I've been pondering every since. The question basically boils down to two things:

• How do you manage Eclipse's .classpath file in conjunction with lib.properties (the file that manages it for Ant)?
• When using AppFuse for multiple projects, do you put a "lib" folder in each project or use a central repository?

Quick Answers: I replace files in the appfuse/lib directory and update lib.properties. Then I update my project properties in Eclipse to reference the new jars. A pain, yes - but only a 2 minute process. I run all my tests before I bother changing the Eclipse classpath. As for multiple projects - the easiest thing to do is to move $yourProject/lib to a folder called "libs" in the same directory as $yourProject and change the ${lib.dir} property in properties.xml to point to the new folder.

Begins Rambling... I'm currently using AppFuse on 3 different projects. 1 is AppFuse itself, the 2nd is Struts Resume, and the third is for a client I created a webapp for in August. Right now, when I synch up Struts Resume with AppFuse, I copy paste from appfuse/lib to struts-resume/lib and update the lib.properties appropriately. I can't just copy lib.properties to struts-resume/lib because struts-resume uses libraries that appfuse doesn't. Yes, this is admittedly a pain in the arse. It's almost as bad as changing all the method signatures when moving the Hibernate Session from all method signatures into the constructors (can your IDE do that?!). I don't want to make people download appfuse to build struts-resume though, so I doubt I'll change this process.

The whole "massive lib folder" has been bouncing around in my head for quite some time. I'd like to use Maven or Greebo to download the dependencies for AppFuse, but at the same time, it's nice being able to download the whole thing at once and be up and running. I don't want to go the Maven route because I don't really want/need a website for AppFuse and it sounds tough to get it working with XDoclet (though WebShop looks like it might be a good template). KISS

The project.xml in AppFuse is my feeble 20-minute attempt to get it Mavenized (it's currently not used). I tried Greebo this morning, and it really does nothing for me. Especially since I've setup separate compile/test classpaths (read from lib.properties). It'd be a real pain with Greebo to separate out the classpath's for testing and building - it seems to only support one long classpath. Also, who wants to make their whole best-practices open-source app dependent on a 0.1 open-source app?

As for having my IDE (wether it be Eclipse or IDEA) reading the classpath from Ant - that would be the sweetest feature of the year! Currently in Eclipse and IDEA, I have to give an absolute path to j2ee.jar since I don't want to distribute it (it's 11 MB). When I switch b/w OS X and WinXP, I always have to change this classpath. I'm sure there's an easier way with setting variables in the IDE, I just haven't figured it out yet.

The other thing that is annoying is that IDEA doesn't seem to read my $ANT_HOME environment variable. Does it have it's own $ANT_HOME? It's annoying for me b/c I check for JUnit classes in the classpath in my "init" task, and IDEA doesn't find them. Don't worry Eclipse bashers - it doesn't work in Eclipse either. This is fine with me b/c I prefer the command line, but those "I use my IDE for everything" folks might not like it because they can't run AppFuse's build.xml file from w/in their IDE.

Upgrading from Struts 1.1 to Nightly build

I'm upgrading our application at work to the nightly build (20031020) of Struts in order to use the validwhen Validator. I found a few deprecations and errors in the process, so I thought I'd share to help others upgrade easier:

• ActionError has been deprecated in favor of ActionMessage. Likewise, ActionMessages.GLOBAL_MESSAGE replaces ActionErrors.GLOBAL_ERROR.
• Methods in ResponseUtils have been deprecated in favor of TagUtils' methods.
• RequestUtils.message has been deprecated in favor of TagUtils.message. Other methods include RequestUtils.lookup.
• Many of the methods in TagUtils aren't static (they where were in Request/ResponseUtils), so you have to create an instance of TagUtils. Anyone know the logic here?
• ValidatorResources.get deprecated in favor of ValidatorResources.getForm.
• ValidatorForm.getFieldMap() is gone, which no apparent replacement method (at least not in the JavaDocs).
• The Tiles' Controller interface's perform method has been deprecated in favor of execute. You gotta love this one - while perform has been deprecated, you must use it or you will get a compile error saying you must implement it (or declare your class abstract). Same goes for execute. So to upgrade, I had to implement both methods - where my perform method calls my execute method.
• org.apache.commons.lang.NumberUtils moved to org.apache.commons.lang.math.NumberUtils
• org.apache.commons.validator.ValidatorUtil moved to org.apache.commons.validator.util.ValidatorUtils
• stringToInt(java.lang.String) in org.apache.commons.lang.math.NumberUtils has been deprecated. Not according to the its JavaDoc.

Final tally - two deprecation errors that don't seem to have replacements (yet):

    [javac] .../src/web/org/appfuse/webapp/filter/BreadCrumbFilter.java:182: 
        warning: stringToInt(java.lang.String) in 
        org.apache.commons.lang.math.NumberUtils has been deprecated                                                                                                  
    [javac]        int mSS = NumberUtils.stringToInt(temp);                                    
    [javac]                                  ^                                                      
    [javac] .../src/web/org/appfuse/webapp/taglib/LabelTag.java:71: warning: 
        getFieldMap() in org.apache.commons.validator.Form has been deprecated                              
    [javac]        Field field = (Field) form.getFieldMap().get(fieldName);               

Later: Thanks to Steve Raeburn (via the struts-dev mailing list), I now have no deprecation errors. NumberUtils.stringToInt(String) is now NumberUtils.toInt(String) and Form.getFieldMap().get(String) is now Form.getField(String). Thanks Steve!