Raible Designs

Using Ivy in AppFuse

I'll admit, the thought of not checking in JARs to AppFuse's CVS is intriguing. With Ivy, I think I could pull off the current setup, plus a dynamic-downloading system. By current setup, I mean that the JARs are distributed in your "lib" directory and you can build your app w/o downloading any dependencies. I like this because I can develop AppFuse and not worry about my internet connection.

Dion doesn't get my love for checking in JARs. The main reason I do it is because it takes me a less time to download a new release and check it into CVS than it takes me to find that same release in Maven's Repo. Case in point: Hibernate 3.

I love the idea of Ivy, and mockhaug makes it sounds great, but I don't want to have to create a bunch of metadata whenever I want to use something like Hibernate 3. Then again, if Ivy is ever going to catch on, someone has to do it.

In conclusion, I'm still not convinced I should integrate Ivy into AppFuse - sounds like maintaining and uploading dependencies would be a lot more work than just checking in JARs. If there was a person responsible for creating Ivy metadata every time a new release came out, I might think different.

Maven 2 Alpha - looking good!

I saw that the Maven 2 Alpha was released today and decided to give it a spin. The two features in Maven 2.0 that look compelling to me are 1) speed and 2) transitive dependencies. I've been using Maven 1.x on my current project since January and I still don't like it. Why? It's dog slow on my PowerBook (but tolerable on my Windows box) and you have to specify a shitload of dependencies when developing an app with Struts+Spring+Hibernate.

Maven 2 looks good, and it does seem to startup as fast as Ant (at least on Windows). Just typing "m2" completes in about a second, and so does typing "ant". Typing "maven" takes about 3 seconds (even though it reports it only took 1 second). I look forward to seeing Maven 2 evolve. I wonder if we should rewrite our POMs for Maven 2 (we current have 11 sub-projects)? We'd probably be a pretty good test-bed, but I don't think Maven 2 supports all the 1.x plugins - does it?

I doubt I'll use Maven 2 with Equinox or AppFuse this year - mostly b/c I don't expect it to be released until 2006. I do like the looks of Ivy and I've considered re-writing AppFuse's monstrous build.xml file using JAM. If I were to use Ivy, I think I'd still release with all JARs in a local "lib" directory. The nice thing about Ivy is it would give users the option of checking JARs into source control (currently, it's required).

Even after using Maven for several months, I still like local JARs better than downloading. It does make a lot of sense in a multi-project environment though.

As for JAM, I don't like it for two reasons: 1) it uses the non-transitive dependency listing like Maven 1.x and 2) it requires you install JAM and set a $JAM_HOME. I'd prefer to keep AppFuse to one build tool - Ant or Maven (or both).

I suggested a large refactoring of the build process (and collapsing of the source trees) for AppFuse 1.9, but it was rejected by users for the most part. Their opinion: the build process works great, we like it - work on other stuff that's more important (code generation, tools support, etc.). Another thing that's suprised me about AppFuse users is the relatively small number of folks that have requested support for appservers other than Tomcat. To date, I don't think I've had a single Resin or Orion request, but I've had plenty of WebLogic, WebSphere and Sun App Server requests. The most compelling reason to use JAM for building/deploying/testing AppFuse is for its server support, but if I don't need it, why add the complexity?

I guess some things just work, and there's no reason to fix them if they aren't broken. Maven 1.x is not one of those things IMO. It's good to see the improvements coming in Maven 2.

Upgrading to Spring 1.2 RC1 and Hibernate 3.0

I spent an hour or so on Friday upgrading Equinox and AppFuse to use Spring 1.2 RC1 and Hibernate 3.0. The upgrade for AppFuse was relatively painless, but the upgrade for Equinox failed. Equinox uses HSQLDB version 1.7.1. The main reason I use the 1.7.1 version is to avoid the infamous "lock exception" that the new HSQL version throws in standalone mode. With version 1.7.1, it seems you could have more than one connection open to the file-based database w/ no problem. I really like this feature in 1.7.1 b/c it means you can run the app in Tomcat and browse the database at the same time.

So what's the problem? Why can't I just use Hibernate 3.0 with HSQL 1.7.1? The problem is I like using the following setting as part of my "sessionFactory" bean:

<prop key="hibernate.hbm2ddl.auto">update</prop>

This setting will update the schema when you change mapping files, but otherwise leave the data intact. Furthermore, it'll actually create the tables if they don't exist. Not so with Hibernate 3. With Hibernate 3, using "update" doesn't create the tables. Of course, upgrading to a newer version of HSQL fixes the problem, but then I get the lock problem. My eventual solution will probably be to hack Hibernate or HSQL, but for now I just won't upgrade Equinox. Another solution might be to look at some other embedded databases. Of course, I could also require users to install a database to run Equinox - but I like having the "no setup required" feature.

Regardless of the problems I experienced with HSQL and Hibernate 3, upgrading AppFuse was pretty painless. Here's the set of instructions I sent to the mailing list:

1. Download Hibernate 3.0 and Spring 1.2 RC1.
2. Create a lib/spring-1.2-rc1 and put the following files in it (NOTE: spring.jar now contains aopalliance.jar):

       acegi-security-0.8.1.jar
       commons-codec.jar
       ehcache-1.1.jar
       license.txt
       spring-mock.jar
       spring.jar

3. Create a lib/hibernate-3.0 and put the following files in it:

       hibernate3.jar
       lgpl.jar
       lib/antlr-2.7.5H3.jar
           antlr.license.txt
           asm.jar
           c3p0-0.8.5.jar
           c3p0.license.txt
           cglib-2.1.jar
           dom4j-1.5.2.jar
           jta.jar
           jta.licence.txt
           oscache-2.1.jar
           swarmcache-1.0rc2.jar

4. Change the versions for Hibernate and Spring in lib/lib.properties. Also, change the hibernate.jar property to reference hibernate3.jar instead of hibernate2.jar.
5. In build.xml, change the "package-web" target to include all the Hibernate JARs instead of just specific ones:

   <lib dir="${hibernate.dir}/lib" includes="*.jar" excludes="jta.jar"/>

6. Change web/common/taglibs.jsp to use uri="/oscache" for the oscache taglib.
7. Search for "net.sf.hibernate" and replace it with "org.hibernate".
8. Search for "orm.hibernate" and replace it with "orm.hibernate3" (for Spring).

The major difference for Hibernate is you no longer need odmg-3.0.jar, but you do need asm.jar and antlr-2.7.5H3.jar. Let me know if you find any issues with these instructions. You could also just download AppFuse from CVS.

NOTE: The CVS version of AppFuse has an XDoclet version that only supports generating Hibernate 2.x mapping files. I believe there is support for Hibernate 3 in XDoclet's CVS - but I haven't had a chance to upgrade yet.

Update: Here's more on the HSQL bug that's not really a bug (according to a comment on the post). Regardless of whether it's a bug or not, it'd be nice to have the 1.7.1 behavior as an option - it's a great feature for get-started-quick apps like Equinox.

Fun with jWebUnit and Canoo WebTest

For the past few days, I've been messing around with jWebUnit and Canoo WebTest at my "day job". I say messing around because I've mainly been trying to overcome perceived bugs with both projects. I'm used to using Ant and both of these libraries "just work".

The problem I had with jWebUnit is that the setOption(selectName, optionLabel) didn't work for me. This turned out to be some sort of conflict with SiteMesh, and when I commented out the SiteMesh <filter-mapping>, everything worked as expected. This is quite strange since I use SiteMesh+jWebUnit with Equinox. I tried to reproduce the problem with Equinox by adding a <select> with <option> elements, but it all worked fine there. I'd blame it on Maven, but I was running my tests from IDEA. As a workaround, I subclassed SiteMesh's PageFilter and stopped processing when the user-agent.startsWith("httpunit"). This is very similar to the JCIFS and jWebUnit workaround we're using.

Before I figured out the jWebUnit/SiteMesh issue, I decided to try my favorite UI testing tool: WebTest. Since we're using Maven, I figured the Maven Canoo Webtest Plugin would be the way to go. This took me about a day to get working (so much for the ol' 10 minute test). Most of the problems where related to the fact that setting the properties didn't seem to have any effect. I ended up writing my web-tests.xml much like I would with Ant - with taskdefs and importing project.properties for the properties to take effect. Last night, after I couldn't get webtest to click a button, I decided to try the same XML file with Ant. I dropped it into AppFuse, changed a few settings and voila! - it all worked! "WTF?" I thought to myself. Turns out the Maven Plugin is from October 2004 and is based on build 543. I ended up rebuilding the plugin to build 733 and then everything worked fine. Here's the patch.

Now that I got them both working, I'm leaning towards using jWebUnit because I can use Java to get the last inserted id (for fullying CRUDing an object). With Canoo, I'd have to use our query interface, add a feature to sort by id (or somehow get the last record added), then click on it to edit the new record. To make matters worse, the API we're talking to right now let's us add records, but we can't fetch them back - no matter what we query by. We've tried both the web services interface and the EJB one with the same results.

Ahhh, the life of an enterprise developer - trying to make 3 systems talk to each other and all of them have broken (or non-existent APIs). For one system, we're actually going through their web interface with httpclient to do CRUD on records!

Rails is 8 times slower than Spring+Hibernate

Might as well start off this week by getting people's blood boiling. According to a comment on Dion's blog:

Having done extensive performance (scalability means different things to different people) testing on both Rails and a comparable Spring/Hibernate/JSP2 webapp (no one seems have have done any sort of benchmarking on Rails, or they simply don't care, I don't really know, but since benchmarking is what I do... ) I can say that Apache2/FastCGI/Rails is about... 8x slower than the comparable Tomcat/Spring/Hibernate/JSP2 solution. And that is with caching turned on in Rails (using Rails 0.9.5...)

Quite frankly, 62 req/s on a Dual Opteron with 4GB of RAM rendering a simple view with no DB access is too... damn slow.

Personally, I still think Rails looks like a great (and easy) way to develop webapps. I just wonder if there's some truth to the "can't scale" argument. I guess the best way to find out is for me to develop an application like AppFuse with Rails, and then hammer it (and AppFuse) with JMeter to see what kind of results I get.

On a sidenote, I wonder when Rails will hit the illustrious version 1.0? They released 0.1 last week - which is a bad version number for marketing. If it's as mature as folks claim, why not make the next release 1.0? That version number alone will likely allow developers to use it more in big companies.

[ANN] Equinox 1.3 Released

This release is mainly a bug fix release, but it also adds support for Maven. All of the frameworks used in Equinox, as well as its build/test system is explained in Spring Live. Detailed release notes are below:

- Added missing "validator" property to "userFormController" bean in Spring MVC version.
- Added "redirect" element to success mapping to user list to prevent duplicate post problem.
- Moved "ctx" variable declaration from decorators/default.jsp to taglibs.jsp so it's available to all JSPs.
- Changed any references to UserDAO in UserWebTest.java instances to use UserManager instead (to prevent problems when transactions aren't used).
- Fixed install scripts in extras so they'd work on Windows from the command prompt. Added "fixcrlf" target for users that encounter issues.
- Added installer for Maven in "extras/maven". This can be used to replace the Ant build system.
- Dependent packages upgraded:

• Display Tag 1.0
• Hibernate 2.1.8
• iBATIS 2.0.9b.550
• JPOX 1.1.0-beta-1
• Spring 1.1.4
• Tapestry 3.0.2

Download. For more information about installing the various options, see the README.txt file.

Demos:

• Spring
• JSF
• Struts
• Tapestry
• WebWork

Rather than uploading the different combinations that are possible with Equinox, I figured I'd just wait for requests. So if you'd like things like Tapestry+Spring+JDO, or JSF+Spring+JDBC, let me know and I'll upload a pre-built version of 1.3.

Why doesn't AppFuse use Maven?

My newest reply for why AppFuse doesn't use Maven is going to be this link. Ant rocks. I still need to update AppFuse's build.xml to use all the Ant 1.6 stuff - that's scheduled for next week's late nights.

Context Reloading in Tomcat 5.5.7

Today I started using Tomcat 5.5.7 instead of 5.0.28. It was fairly easy to install on my PowerBook - I just had to add the xerces and jmx JARs from the compat package to get things working. The one thing I noticed that's different from Tomcat 5.0.28 is that when I deploy any file, it reloads the context. This can be a pain when I'm just copying JSPs into the webapps directory. I'm willing to admit it could be a problem with my "maven deploy" goal, but since this didn't happen on 5.0.28, I suspect it's the newer version of Tomcat. On 5.0.28, the context was only auto-reloaded when I updated files in the classpath.

The main reason this was frustrating is because we look up a bunch of data from a web service on app startup. The API we're talking to is nice and slow and it takes almost 50 seconds to start our application. Rather than go back to the older version of Tomcat, I wrote some code to serialize all the ServletContext variables to disk, and then check for that file on startup. If the file exists, it deserializes it and puts all the objects back in the ServletContext. Works pretty good and certainly speeds up my development environment. After all this, I'll probably downgrade to 5.0.28. Auto-reloading when classpath files change seems like a better way to go.

AppFuse not for Rookies

Adrian Sutton hits the nail on the head:

...for seasoned veterans who understand (its) technologies well, AppFuse should be a big time saver. I can see a lot of beginners getting into very deep water with it though.

AppFuse can help you get started quickly, but it won't help you really learn how to use the different technologies. Its tutorials are designed to show you how to CRUD a simple object, but that's about it. For learning the different frameworks, that's what books are for. Technical authors put a lot of time and energy into writing. A good way to show your appreciation is to buy their books.

My Recommendations:

• Java Development with Ant - you'll be amazed at how much this book explains AppFuse's build.xml. This book inspired AppFuse (thanks Erik!).
• Pro JSP - AppFuse was the sample app for my chapters in this book. Explains many of the security features in AppFuse.
• Hibernate: A J2EE Developer's Guide or Hibernate in Action.
• Web Frameworks: Struts in Action (or update-to-date with Struts Live), Tapestry in Action, Core JSF.
• Spring Books.

Maven Console and setting properties

I've been using Maven at my new gig and the Maven Console in order to avoid its painfully slow startup times. Using a slow-ass PowerBook in conjunction with Maven makes my face turn read and my ears smoke sometimes, but I'm getting used to it, much to my dismay. While the console has made things tolerable, Maven itself keeps getting in the way. I hate how it *requires* me to run my tests everytime I build or deploy. So I've turned that off by creating a build.properties file with "maven.test.skip=true". The problem with the Maven Console is it doesn't let me turn tests back on, so I'm stuck with running "maven test -Dmaven.test.skip=false" when I want to run my tests.

There's two ways I can think of to solve this problem:

• If "maven idea:multiproject" allows me to setup my project so that Tomcat/Resin/whatever can point to my source directory and I don't have to deploy. I'm a web developer, and I typically have to run "maven deploy" to test simple UI changes. That's why I turn the tests off - because I want a 1-2 second turnaround to see my changes. BTW, it's too bad there's no "eclipse:multiproject" goal.
• Enhance the console so it's possible to set properties. For example, typing "-Dmaven.test.skip=false" would set the property so the next time I run "maven war", my tests would be run. That, or allow me to run "maven war -Dmaven.test.skip=false". Allowing this would also make it possible to run a single test from the command line, instead of all (the only current option).