Raible Designs

Integrating Compass with AppFuse and the Display Tag

ChenRanHow has written up a detailed tutorial on how to integrate Compass with AppFuse and the Display Tag. From his mailing list post:

• Part 0. Overview of the practice
• Part 1. Setup env, add Compass and related library to AppFuse
• Part 2. Create ant tasks for create and delete index
• Part 3. Use annotation to make Compass resource mapping
• Part 4. Create Struts action to perform search
• Part 5. Make DisplayTag work with Compass

Thanks ChenRanHow!

Another great tutorial was recently written by Luciano Fiandesio. If you're looking to use Quartz, checkout Luciano's (well styled) AppFuse and Quartz tutorial.

In other AppFuse news, FanYang has started translating the documentation to Japanese, Mike McMahon has converted the appfuse-hibernate module to annotations, CruiseControl is continually testing, Mike Horwitz has solved most of the "Maven doesn't read a WARs dependencies" issue, and Scott Ryan is still hard at work on the code generation plugin. Even better - we've asked Scott to come aboard as a committer and he's accepted. Welcome aboard Scott - we appreciate all the work you're doing.

As far as progress on AppFuse 2.0, we're almost done with the Maven 2 conversion. The only thing left is figuring out how to get Mike's maven-warpath-plugin to hook into the Eclipse and IDEA plugins to they generate project files correctly. After that, it's time to start on documentation. I'm still torn on if we should use Confluence or DocBook. However, after looking at Spring's documentation for the past week, I think DocBook is probably the better choice. Then again, Stripes' Confluence Wiki looks nice and organized.

What do you think? What's the best way to write documentation for an open source project? Which system do you prefer to read? From experience, I prefer reading Spring's documentation over trying to find stuff in WebWork's wiki.

We've had great success with AppFuse users contributing to the documentation via a wiki, and I'd hate to create a documentation system that gets away from that. Maybe a DocBook/Confluence combination is the way to go? It looks like the CeltiXFire folks are having a similar debate.

Continuum vs. CruiseControl for Maven 2

I spent some time this past weekend getting automated builds setup for AppFuse 2. Since the project now uses Maven 2, I figured I'd give Continuum a try. I pointed it at my pom.xml in SVN and expected everything to work out-of-the-box. No dice. It seems that Continuum reads the artifactIds instead of the module names for sub-project resolution. To workaround this issue, I'd basically have to rename all my sub-projects to have an "appfuse-" prefix. Doesn't that violate the whole DRY principle? Sure, there's projects that do this, but there's others that don't.

Since I didn't feel like renaming the modules/directories in SVN, I gave CruiseControl a try instead. It took a bit of elbow grease on my part, but I ended up with a config.xml file that works splendidly. It seems somewhat ironic to me that the CruiseControl works better with Maven 2 than Continuum does.

AppFuse 2.0 Status

Last week I managed to get AppFuse to compile with Maven 2, this week I got all the tests passing. This week, I struggled with Maven's WAR dependencies and how AppFuse will be used by end-users. It was frustrating, but I think I got most everything figured out. Unfortunately, there's still many issues to be sorted out.[Read More]

AppFuse 2.0 Status

I managed to get most of AppFuse's code moved over to a Maven 2 structure this week. I have tests working in the hibernate/ibatis projects, as well as the service project, but not in the web tier projects yet. I do have everything compiling though.

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] AppFuse ............................................... SUCCESS [2.228s]
[INFO] AppFuse Common Data Module ............................ SUCCESS [1.681s]
[INFO] AppFuse Hibernate Module .............................. SUCCESS [0.809s]
[INFO] AppFuse iBATIS Module ................................. SUCCESS [0.630s]
[INFO] AppFuse Data Modules .................................. SUCCESS [0.008s]
[INFO] AppFuse Service Module ................................ SUCCESS [0.696s]
[INFO] AppFuse Common Web Module ............................. SUCCESS [2.817s]
[INFO] AppFuse JSF Module .................................... SUCCESS [4.410s]
[INFO] AppFuse Spring MVC Module ............................. SUCCESS [4.038s]
[INFO] AppFuse Struts 2 Module ............................... SUCCESS [4.954s]
[INFO] AppFuse Tapestry Module ............................... SUCCESS [4.042s]
[INFO] AppFuse Web Modules ................................... SUCCESS [0.007s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 26 seconds
[INFO] Finished at: Fri Aug 18 15:06:54 MDT 2006
[INFO] Final Memory: 11M/26M
[INFO] ------------------------------------------------------------------------

If you'd like to review any of the work done thus far, I've uploaded my latest work to:

http://static.appfuse.org/downloads/appfuse2-20060817.zip

The major issue I've encountered to date can be reviewed on the Maven user mailing list. If you happen to try things out, the best thing to do is post feedback to the dev list. I'm considering another device-free weekend, so I may not respond until Monday.

Comparing Open Source Application Servers

With all the recent hubbub about GlassFish, I decided to do a quick performance test this morning. I downloaded all the most recent versions of the various open source application servers, deployed AppFuse 1.9.3 (Struts version) on them, and ran "ant test-canoo" to see if any of them were faster than the other. This was by no means a scientific, isolated test. It also didn't take into account any performance tuning you should do on these servers, I just used the out-of-the-box settings.

I ran these tests on my MacBook Pro (2.16 GHz Intel Core Duo, 2 GB DDR2 SDRAM) with my JAVA_OPTS set to:

-Xms768M -Xmx768M -XX:MaxPermSize=512m -Djava.awt.headless=true

When typing "java -version" at the command line, I got:

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-103)
Java HotSpot(TM) Client VM (build 1.5.0_06-57, mixed mode, sharing)

Servers tested (in no particular order):

• JBoss 4.0.4
• GlassFish B48
• JOnAS 4.7.6
• Resin 3.0.21
• Geronimo 1.1

I'm pleased to note that all servers allowed me to deploy appfuse.war without using a console or command-line tool. They all support dropping the WAR in some sort of auto-deploy directory. Very cool! Secondly, I was able to successfully deploy AppFuse on all of them with no changes to AppFuse nor the server. Quite impressive.

My test consisted of the following:

• Copying appfuse.war into the appropriate directory
• Starting the server
• Running "ant test-canoo" from my $APPFUSE_HOME directory once
• Running "ant test-canoo" 3 times, recording the numbers for each run

Here's what I found:

Since I know you're going to ask about Jetty and Tomcat (the two main servlet-only containers), I ran the numbers on those too. First off, I tried Jetty 6 RC0. No dice - I got the following error when trying to start the server.

java.lang.IllegalStateException: Cannot initialize context because there is already a root application 
context present - check whether you have multiple ContextLoader* definitions in your web.xml!
        at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:173)

Since AppFuse deploys on all the above app servers, as well as Jetty 5.1.x, I'll chalk this up to a bug in Jetty 6. I used Jetty 5.1.11 for this test because I already had it installed on my machine.

I don't know that these numbers mean anything, but it was a fun experiment. For those of you who think these numbers might mean something, here's the rankings:

1. Tomcat 5.5.17
2. Resin 3.0.21
3. JBoss 4.0.4
4. Jetty 5.1.11/GlassFish B48 (tie)
5. Geronimo 1.1
6. JOnAS 4.7.6

Of course, the better test would be hammering each server with 1000 concurrent users (or a number higher than that) and comparing how each server holds up.

AppFuse Roadmap updated for 2.0

I've updated the AppFuse Roadmap for the upcoming 2.0 version. The current plan is to have a few milestone releases before the final 2.0 release. I can't promise any specific release date because of developer's schedules and current commitments. However, my hope is we can have it done by the end of this year.

Milestone 1

• Maven 2 integration
• Migrate from CVS to Subversion
• Remove XDoclet, putting generated files into source tree
• Get all flavors (WARs) deployed and running on Tomcat and Jetty Maven Plugin
• Spring 2.0: Upgrade XML to XSDs, annotations where appropriate
• Upgrade WebWork to Struts 2
• Documentation - move to new Confluence or DocBook-based system for 2.0 documentation

Milestone 2

• JDK 5, Annotations and JSP 2.0
• Archetypes for creating new AppFuse projects
• Documentation, including screencasts for tutorials

Milestone 3

• Integrate XFire by default (for existing classes and generated classes)
• Code Generation/AppGen - hopefully with the AppFuse Maven Plugin
• Documentation

2.0 Nice to haves

• TestNG replacing JUnit
• Hibernate Validation Annotations (hard part is hooking it into the web frameworks)
• Tomcat Plugin for Maven (that operates like Jetty's plugin)
• JPA Support
• Support for JDK 1.4 using something like Retroweaver
• Support for using Ant to build/test/deploy AppFuse-based projects
• Someone to do all the documentation ;-)

Let me know if there's anything that seems to be missing from this list.

If you can't wait until the end of this year, you may take a look at Patrick Lightbody's newly announced Project Able. He has a lot of good ideas in there that I hope to learn from.

7 simple reasons to use AppFuse

IBM developerWorks published my "Seven simple reasons to use AppFuse" article today. Here's a summary:

Getting started with open source tools for the Java™ platform such as Spring, Hibernate, or MySQL can be difficult. Throw in Ant or Maven, a little Ajax with DWR, and a Web framework -- say, JSF -- and you're up to your eyeballs just trying to configure your application. AppFuse removes the pain of integrating open source projects. It also makes testing a first-class citizen, allows you to generate your entire UI from database tables, and supports Web services with XFire. Furthermore, AppFuse's community is healthy and happy -- and one of the few places where users of different Web frameworks actually get along.

While you're there, you might be interested in reading the "Introduction to Spring 2 and JPA" tutorial. I don't know if we'll get JPA support into AppFuse 2.0, but it's certainly a possibility.

As far as AppFuse 2.0, here's the current structure I've started on for Maven 2:

appfuse
    - data
        - hibernate
        - ibatis
    - service
        - pom.xml
        - src
    - web
        - jsf
        - spring
        - struts
        - tapestry

After code is moved into the directory structure above (or completely re-written), I'd like to move to working on creating single module archetypes and multi-project archetypes (data, service, web) with Maven 2.

After getting the Maven 2 structure checked in, hopefully we can start looking at replacing AppGen. Scott Ryan has done a fair amount of work on this so far with his AppFuse Maven Plugin.

I plan on documenting the plan of attack and milestone features for 2.0 sometime this week.

Update: I started working on the Maven 2 conversion last night. The above structure has changed slightly. Now there's a project in data and web (notice the pom.xml and src in these directories). These projects will contain the classes/files that are common to their sub-projects. The fact that these projects even exist will likely be transparent to the end user.

AppFuse 1.9.3 Released

This release is primarily a bug fix release, but also contains upgrades to several dependent libraries, including Acegi Security 1.0.1.

To install and configure AppFuse for development, see the QuickStart Guide. Thanks to all the sponsors who have contributed products and free hosting to the project.

• Download
• Release Notes
• Learn more about AppFuse

To see how AppFuse works, please see the following demos (username: mraible, password: tomcat):

• Struts + Spring + Hibernate
• Spring + iBATIS
• WebWork + Spring + Hibernate
• JSF + Spring + Hibernate
• Tapestry + Spring + Hibernate

Comments and issues can be sent to the mailing list or posted to JIRA.

Note: If you're building AppFuse on Linux, you should be aware of some non-English encoding issues. The solution is to add the following to your ~/.bashrc file.

export LC_CENGINE=en_US
export LANG=en_US
export LANGUAGE=en_US

RE: What Web Application framework should you use?

Tim O'Brien has an interesting post titled What Web Application framework should you use?. The first thing I noticed about this post is the permalink. It looks like he started with "Isn't Rails supposed to change...", which makes me wonder what the rest of the title was. In this post, he rags on Java Web Frameworks and the lack of a clear path for choosing one. He ends up predicting that many will stick with Struts 1.x (poor bastards) and those that aren't tied to Java should move to Rails. I don't have a problem with folks moving to Rails, but I would like to comment on the Java Web Framework space and Tim's comments.

He says:

Prediction: The confusion over what is happening over at Struts is going to discourage people from continuing to use it. The Struts team did the right thing in recognizing that Struts 1.x was a dead-end, but that project needs a single public message. Is it Struts Action or is it Struts Faces? Or is it two frameworks capitalizing on the Struts brand name?

I think what is going on in the Struts project is definitely two frameworks capitalizing on a brand name. That was a concious choice on the project's part when they chose to start creating sub-projects. The interesting thing about Struts Shale is it's largely a prototype for JSF 2.0. Furthermore, it was rejected by many Struts developers as becoming Struts 2.0. Why? Because JSF sucks. Especially when used with JSP - which is what most folks are doing.

JSF continues to be the most over-hyped under-used framework in Javaland. If you read the blogs of first-time users, you'll find many complaints and issues on how things work. Granted, most of these problems are with JSP and the implementation, but still. If I were in charge of JSF, I'd dump JSP altogether, bundle Facelets with it and allow more flexible page navigation (including controller-to-page). Don't get me wrong, I like the ideas behind JSF, I just don't like the implementation (or the fact I have to wait years for things to be fixed in the spec).

That being said, I've yet to meet an unhappy WebWork fan. If you find someone that still likes Struts, ask them if they've used WebWork. Chances are they'll say no. As far as Tapestry is concerned, the learning curve is too high. It's been rejected time and time again by my clients because of the learning curve. Are they going to fix this? Yep, they're going to re-write the whole damn thing - again! Every major point release of Tapestry throws backwards-compatibility out the window. Furthermore, I've heard once you get over the learning curve, it's a joy to work with. I've also met people at conferences that've used it over a year and say they're still struggling with its concepts.

Spring MVC - I wish I had bad things to say about it, but I don't. It (obviously) has the best Spring integration, but I've found WebWork much more pleasurable to work with. Sure, Spring has a ThrowawayController, but with a name like that, you can tell it's a second-class citizen.

Inspired by Tim's post, here's my prediction:

Struts Action 2 will be the best choice for developing Java-based web frameworks. Not only does it support JSF, but it's easy to learn, test and use. Furthermore, it seems to be the most often used framework in major software products and web sites.

How's that for a clear message? Struts Action 2 is the shiznit, now let's get back to developing applications.

Disclaimer: This is my opinion with a lot of stuff thrown in to get folks riled up. I've never put a JSF, Tapestry or Spring MVC application into production (except for AppFuse of course), so most of my opinions are likely without foundation. In wonder how many applications Mr. O'Brien has put into production with these frameworks?

[ANN] AppFuse 1.9.2 RC1 Released

The primary reason for this release is to integrate Mike Stenhouse's CSS Framework. Since this involves many UI changes, we're publishing a release candidate that uses Herryanto Siatono's "simplicity" theme. For the final 1.9.2 release, we hope to offer themes from all the CSS Framework Design Contest Winners.

To install and configure AppFuse for development, see the QuickStart Guide. Thanks to all the sponsors who have contributed products and free hosting to the AppFuse project.

• Download (now points to 1.9.2 final)
• Release Notes
• Learn more about AppFuse

To see how AppFuse in action, please see the following demos (username: mraible, password: tomcat):

• Struts + Spring + Hibernate
• Spring + iBATIS
• WebWork + Spring + Hibernate
• JSF + Spring + Hibernate
• Tapestry + Spring + Hibernate

Comments and issues can be sent to the mailing list or posted to JIRA (please use version 1.9.2). Hopefully we can release 1.9.2 final in the next week or so.

Update: I've finished a first stab at integrating the puzzlewithstyle and andreas01 themes. I've only tested these in Firefox so far, but you can see them in action on the demo site using the webwork and jsf flavors.

Update 2: 1.9.2 Final has been released.