Raible Designs

Comparing Java Web Frameworks: Proposed Outline

I'm just now starting to create my Comparing Java Web Frameworks presentation for ApacheCon Europe. According to Dave, I'm way late on submitting my presentation. However, I haven't received any late notifications from ApacheCon's organizing committee, so I don't feel too bad.

I think it's interesting how most conferences don't spend much time organizing from a speaker's perspective. The Colorado Software Summit and NFJS are two exceptions. As a speaker, you always know exactly what's going on, what the deadlines are and where you're supposed to be when. With ApacheCon, I feel like I'm in the dark on almost everything - including if I have a hotel room or not. I guess that's the difference between a volunteer organization and conferences where the organizers make money.

Luckily, I've done this presentation quite a few times in the past, so it's mostly an update rather than a rewrite. The biggest changes: dropping Struts 1 and adding Stripes and Wicket. Of course, I could keep Struts 1 since it's not much additional work, but since I only have 50 minutes for the talk (10 minutes for QA), it makes sense to drop it. And yes, I know many of you'd like to see Grails, Seam, GWT, RIFE and Click added to this presentation - but no one wants to sit through a presentation on 11 web frameworks in 45 minutes.

Here's the abstract for the session:

One of the most difficult things to do (in Java web development) today is pick which web framework to use when development an application. The Apache Software foundation hosts most of the popular Java web frameworks: Struts, MyFaces, Tapestry and Wicket. This session will compare these different web frameworks, as well as Spring MVC and Stripes. It will briefly explain how each works and the strengths and weaknesses of each. Tips, tricks and gotcha's will be plentiful. Lastly, it will provide attendees with a sample application that utilizes all 6 frameworks, so they can compare line-by-line how the frameworks are different. This sample application will include the following features: sortable/pageable list, client and server-side validation, success and error messages as well as some Ajax functionality. The frameworks will be rated on how easy they make it to implement these features.

Without further ado, here's my proposed outline:

• Introductions (5 minutes)
• Pros and Cons (15 minutes, ~2 minutes for each)
• Sweetspots (10 minutes)
• Smackdown - evaluation criteria includes (15 minutes)
  • Ajax support
  • Bookmark-ability
  • Validation (including client-side)
  • Testability (esp. out-of-container)
  • Post and redirect
  • Internationalization
  • Page decoration
  • Community and Support
  • Tools
  • Marketability of skills (can it help you get a job)
  • Job count (is there a demand for skills on Dice)
• Conclusion (5 minutes)
• Q and A (10 minutes)

During the Pros and Cons, I won't be showing any code like I usually do - there's just not enough time. I'm also adding in a discussion on these frameworks' sweetspots. The Pros and Cons section is largely my opinion, and I think it's important to hear the framework authors' opinions as well.

In evaluation criteria, I'm dropping List screens and Spring Integration. All these frameworks have good Spring support and most support some sort of page-able/sortable list. I can add either of those back in based on your suggestions.

Any feedback is greatly appreciated.

Configuring Tomcat for Production

From The Atlassian Developer Blog:

You appear to be running Tomcat in development mode. (http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html)

This means that source of every JSP is held in memory to provide detailed messages in the event of an error. If you have large JSPs this will hurt. It looks like this accounts for 50MB+

From Tomcat's Production Configuration documentation:

Seems like good information to know.

JSF still sucks?

Granted, this post about how painful JSF is is almost 6 months old, but I think it's still mostly true.

Want to compare times? More than three man-weeks have been spent fixing silly JSF navigation problems. A full CRUD AJAX interface with Spring MVC and prototype in the same project took four days, and there was no previous experience with Spring MVC.

If you're going to use JSF, I highly recommend Facelets or Shale/Seam. However, those are mentioned as well:

The default view technology is JSP, even when no one in the real world would recommend it; instead, use Facelets, or Clay, or some other non-standard framework. Not trying to be sarcastic here, since Facelets is pretty good, but this complicates the hiring and education of the team and in fact invalidates the selling point of Faces 'being a standard'.

IMO, Facelets is very easy to learn. If you know how to program JSPs with JSF, you should be able to use Facelets in under an hour. When we converted AppFuse's JSF flavor from JSP to Facelets, rarely did the body have to change - we just had to change from taglibs to XML namespaces.

When you are not working with persistent data (if you are living in a cave or developing wizard interfaces) there are two scopes to store model state: the session context, which raises concurrency issues and is not recommended by the Faces community, and the conversation/process/whatever context, which is not standard and imply installing shale or seam to put even more lipstick on the pig.

There's two problems with Shale and Facelets - the activity on these projects is very low. Shale still has its creators around, so even while its seldom used, you can probably still get your questions answered. However, Facelets seems to be suffering from "developer abandonment".

Conclusion: don't use JSF simply because it's a "standard". Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.

If you still want to use JSF, you should probably use Seam, but don't simply use JSF because it's a standard. If it was a de-facto standard, that'd be another story.

Of course, you could also help improve JSF 2.0. But that's not scheduled for release until late 2008. I'm sure 2 or 3 commentors will claim we'll all be using Rails or Grails by then.

Mixing Apache HTTP Server, mod_rewrite and mod_jk

I'm trying to configure Apache and Tomcat to work with a desired architecture for doing A/B Testing on my current project. Our basic idea is that we'll deploy entirely new WAR files when we have a test, then use the magic of Apache's mod_rewrite, mod_jk and possible the UrlRewriteFilter to keep the URLs somewhat consistent between version A and version B. Here's some questions I have for those folks who might've done this before:

1. Is it possible to use Apache's mod_rewrite to map http://www.domain.com/?v=1 to http://www.domain.com/1 (this allows us to have two different applications/wars served up to the same domain).
2. If #1 is possible, what's the RewriteRule for allowing the parameter to be anywhere in the query string, but still allowing the target to use it as the context name?
3. Is it possible to use something in the WAR (likely the UrlRewriteFilter) to produce HTML that has rewritten links (i.e. http://www.domain.com/?id=1 in the WAR whose context is 1)?

In other words, can Apache forward to the correct app going in, and can that app rewrite its URLs so those same URLs are used when going out?

I believe this is all possible. However, I am having difficulty getting mod_jk to allow mod_rewrite to be processed first. If I have the following in httpd.conf, it seems like htdocs/.htaccess gets bypassed.

JkMount /* loadbalancer

Is it possible to configure Apache/mod_jk so WARs can hang off the root, but still use mod_rewrite? If not, the only solution I can think of is to use UrlRewriteFilter in the WAR to forward to another context when a "v" parameter is in the URL. Currently, the UrlRewriteFilter doesn't allow forwarding to another context. The good news is the Servlet API allows it. I got it working in Tomcat (with crossContext enabled) and wrote a patch for the UrlRewriteFilter.

Anyone out there have experience doing A/B Testing in a Java webapp? If so, did you try to disguise the URLs for the different versions?

Update: I've got a bit of this working. The magic formula seems to be don't try to hang things off the root - use mod_rewrite to make things appear to hang off the root.

First of all, I posted a message similar to this post to the tomcat-user mailing list. Before I did so, I discovered mod_proxy_ajp, which happens to look like the successor to mod_jk. AFAICT, it doesn't allow fine-grained rules (i.e. only serve up *.jsp and *.do from Tomcat), so I'll stick with mod_jk for now.

Rather than proxying all root-level requests to Tomcat, I changed my JkMount to expect all Tomcat applications to have a common prefix. For example, "app".

JkMount /app* loadbalancer

This allows me to create RewriteRules in htdocs/.htaccess to detect the "v" parameter and forward to Tomcat.

RewriteEngine On

RewriteCond     %{QUERY_STRING}     ^v=(.*)$
RewriteRule     ^(.*)$              /app%1/ [L]

This isn't that robust as adding another parameter causes the forward to fail. However, it does successfully forward http://localhost/?v=1 to /app1 on Tomcat and http://localhost/?v=2 to /app2 on Tomcat.

What about when ?v=3 is passed in? There's no /app3 installed on Tomcat, so Tomcat's ROOT application will be hit. Using the UrlRewriteFilter, I installed a root application (which we'll likely need anyway) with the following rule:

    <rule>
        <from>^/app(.*)$</from>
        <to type="forward">/</to>
    </rule>

So I've solved problem #1: Using URL parameters to serve up different web applications. To solve the second issue (webapps should rewrite their URLs to delete their context path), I found two solutions:

1. Use mod_proxy_html. Sounds reasonable, but requires the use of mod_proxy.
2. Use the UrlRewriteFilter and outbound-rules.

Since I'm using mod_jk, #2 is the reasonable choice. I added the following link in my /app1/index.jsp:

<a href="<c:url value="/products.jsp"/>">link to products</a>

By default, this gets written out as http://localhost/app1/products.jsp. To change it to http://localhost/products.jsp?v=1, I added the following to urlrewrite.xml:

    <outbound-rule>
        <from>^/app1/(.*)$</from>
        <to>/$1?v=1</to>
    </outbound-rule>

This produces the desired effect, except that when I click on the link, a new session is created every time. AFAICT, I probably need to do something with cookies so the jsessionid cookie is set for the proper path.

Not bad for a day's work. Only 2 questions remain:

1. What's a more robust RewriteRule that doesn't care about other parameters being passed in?
2. What do I need to do so new sessions aren't created when using an outbound-rule?

It's entirely possible that mod_proxy_ajp with mod_rewrite_html is best tool for this. Can mod_proxy handle wildcards like JkMount can? I've heard it's faster than mod_jk, so it probably warrants further investigation.

Update 2: I achieved the desired result using mod_rewrite, mod_jk and the UrlRewriteFilter (for outgoing links). Here's what I put in htdocs/.htaccess (on Apache):

RewriteEngine On

# http://domain/?v=1 --> http://domain/app1/?v=1
RewriteCond     %{QUERY_STRING}     v=([^&]+)
RewriteRule     ^(.*)$              /app%1/$1 [L]

# http://domain --> http://domain/app (default ROOT in Tomcat)
RewriteRule     ^$                  /app/ [L]

And in the urlrewrite.xml of each webapp:

   <outbound-rule>
       <from>^/app([0-9])/([A-Za-z0-9]+)\.([A-Za-z0-9]+)$</from>
       <to>/$2.$3?v=$1</to>
   </outbound-rule>

   <outbound-rule>
       <from>^/app([0-9])/([A-Za-z0-9]+)\.([A-Za-z0-9]+)\?(.*)$</from>
       <to>/$2.$3?$4&amp;v=$1</to>
   </outbound-rule>

Next I'll try to see if I can get it all working with mod_proxy_ajp and mod_proxy_html. Anyone know the equivalent of "JkMount /app*" when using LocationMatch with mod_proxy?

Ant vs. Maven

I found a good post from Steve Loughran on what's wrong with Maven's repositories. I agree with most of his points, but would like to point out mvnrepository.com. This site seems to provide good XML Feeds for what's been uploaded to Maven's Central Repository. If you're using Maven, you should probably subscribe to its Atom Feed.

In related news, Timothy M. O'Brien has an entry about Steve's upcoming book: Ant in Action. This book is the 2nd edition of Java Development with Ant. I have a hard time believing Erik Hatcher is helping Steve write Ant in Action - AFAIK, he's off in Rails-land enjoying himself. Regardless, I'm sure Ant in Action will be an excellent book. Java Development with Ant is one of my favorite technical books of all time and is largely responsible for inspiring me to write AppFuse. I read JDwA way back in October 2002 and used a lot of its code to develop AppFuse 1.x's Ant-based build system.

Like Tim, I still like Ant. However, AppFuse 2.x uses Maven 2 and most of the projects I work on these days use Maven 2. It may surprise some folks, but I actually like Maven 2 (not Maven 1). Sure it has issues, but after a year of using it in anger, I know how to solve most of its quirks. AppFuse 2.x users will benefit from this greatly and I'm thinking of changing its tagline to "We make Maven work."

One of the most interesting things about moving to Maven is we were easily able to make AppFuse more like a framework than a project starter kit. We thought this is what most folks wanted - especially the ability to upgrade a project to the latest version of AppFuse. While some folks wanted this, it seems like most folks liked the full-source version that was a pain-in-the-ass to upgrade. I don't blame them. On the project I'm on, I'll likely be converting to a full-source version before the project is over. That's why APF-675 exists. I doubt we'll make it happen for the 2.0 final release, but it is on our radar of things to do shortly after. With any luck, we'll create a way to migrate projects using embedded AppFuse to full-source AppFuse.

I'd also like to point out something ironic. With AppFuse 1.x, there were a lot of folks that advocated we move to Maven. Their primary reasoning - the Ant build scripts were too long and complicated. How about a good ol' lines of XML comparison for those folks:

• Lines of Ant-related XML in AppFuse 1.x: 1655
• Lines of Maven-related XML in AppFuse 2.x: 2847

Oh wait, that's not a fair comparison. The above number is for AppFuse in SVN, which end users won't deal with. A new project created with AppFuse 2.x will likely have a pom.xml with 634 lines. That's about 1/3 of the amount needed for Ant in AppFuse 1.x. Maven hasn't exactly gotten us away from XML hell though. How about a LOC count for archetypes vs. installers:

• Lines of Ant-related XML for AppFuse 1.x framework installers: 2786
• Lines of Maven-related XML for AppFuse 2.x archetypes (including archetype's pom.xml files): Too much to count. Creating archetypes is waayyyy too complicated IMO. Basic archetypes seem to be around 740 lines (pom.xml for archetype project, archetype.xml and archetype's pom.xml), modular archetypes are around 870. 740 x 4 + 870 x 4 = 6440. I'm guessing the full-source archetypes will add another 5000 lines of XML. Ugh.

This XML-for-archetypes comparison might be unfair as well. With 1.x, you could only create a webapp, with 2.x, you can create a modular application and chop off the web-portion if you so choose.

Of course, the real benefits of moving to Maven are elsewhere. We've seen quite an uptick on the mailing list in the last few months. There's tools cropping up and I've gotten quite a few inquiries about training (yes, I do have a 3-day course on Spring, Hibernate, Ajax, Maven and AppFuse). To me, AppFuse 2.x seems more complicated than 1.x, but it seems the community thinks otherwise. Judging from the increased amount of developer activity on the project, developers seem more interested in a Maven-based system too. Then again, we are making Maven work!

Fenway Park

Time in traffic: 2 hours
Cost for parking: $45
Seeing a Red Sox game at Fenway Park: Priceless

But that's not the best part. The good story behind it all is how my buddy Chris made it happen. I dropped him off at his office on Boylston Street this morning. On the way, I asked him if his company had any seats and if he could "hook it up." He said, "I doubt it, but I'll see what I can do." At 10:00 a.m., his National Sales Manager said that the individual who got the most new contacts in their territory would get tickets to the Red Sox game. Chris worked his ass of all day and won the contest! Not only did he win, but the seats he got were phenomenal - as you can tell from the picture below.

I've never been to a baseball game where the fans were so into it. Everyone stood up and cheered for the last 1/2 hour of the game. The whole experience was incredible - definitely one of the top 10 sports moments of my life. Thanks Chris - you rock!

Going to Fenway?

Today is my first attempt to see a Red Sox game at the illustrious Fenway Park. A couple of weeks ago, I convinced my client I should come out this week (instead of last week) because the Red Sox were in town and I wanted to see a game. Originally, I wanted to go to opening day, but a friend (Chris) who lives here said "It'll be impossible to get tickets, and if you do, it'll be $500 each." Then another friend (Scott) said he had 4 tickets for Thursday's game and I was welcome to one. So I made plans with both of them to go to today's game.

Of course, in the meantime, Chris managed to score a ticket to Tuesday's game and didn't tell me until last night - that bastard!

For most of this week, the forecast has been "snow on Thursday." When I woke to no snow this morning, I figured the game was on and I'd better start heading for Boston. I left my client's office around noon and I arrived in Boston about 15 minutes ago. After paying $30 (!) for parking, I'm now at a Starbuck's - waiting for the game to start at 4.

Scott backed out this morning because he's a sissy, but Chris is still in and scored some tickets off Craig's list. To be honest, it doesn't look good. It's hovering around freezing, windy and poring down rain right now. I got soaked walking the two blocks from my car (sidenote: I got a new Dodge Charger for $30/day from Thrifty - it kicks ass). However, I'm still hopeful. I'm from Montana, so I'm used to miserable weather and I'm sure there's enough tasty beer to make it an enjoyable game. I heard on the radio that they were going to "do their best" to make this game happen. My fingers are crossed. Go Sox!

RE: 5th anniversary of Blogging Roller

From the Blogging Roller himself:

Today is the fifth anniversary of this blog, which I started on April 11, 2002 to promote the Roller blog software that I had just finished writing.
...
Now, five years later, Roller has graduated from the Apache Incubator to become Apache Roller, blog-tech is my full-time job at Sun and I'm still Blogging Roller. Thanks to Roller users and contributors everywhere for helping to make this possible.

Congrats Dave - 5 years is 20 years in Internet Time isn't it?!

It's hard to believe I've been reading Blogging Roller for that long. Thanks to Dave for getting me into blogging and creating Roller. It was his article that got me interested in blogging and inspired me to setup this site. Thanks to Roller, I met Lance, who got Dave and I the Pro JSP deal, which lead me to create AppFuse.

Thanks Dave! I owe you a beer or 12 for all the good things you started.

It's funny to think back when there was only a handful of Java Bloggers: Russell, Dave, Lance, Erik and good ol' Mike. Remember Mike and his "Java blogs" blogroll?

From Vegas to Snow to Boston

Our visit to Las Vegas was a lot of fun. Little did we know, some friends we were meeting there were getting engaged on Thursday night. Of course, the girl (Kim) didn't know, but the guy (Mike) had been planning it for quite some time. We had a great time celebrating with them - as well as at the craps and blackjack tables.

I was planning on staying until Saturday, but Julie made me leave with her on Friday night. Her reasoning was because she was up and I was hemorrhaging cash. I didn't like the idea at the time, but loved it once I slid into my own bed late Friday night.

Leaving Vegas's 90°F temperatures and arriving in Denver's 30°F was kind of a bummer, but the 1" of snow yesterday and today is kinda cool. I leave in a few hours for Boston, where it's supposed to be cold all week. I was hoping for a warm and sunny Red Sox game on Thursday, but with a forecasted high of 40°F it doesn't look like it's going to happen. Oh well, bad weather means I'll probably bill and work on AppFuse more, so it's not necessarily a bad thing.

Happy Easter Everyone!

Update: I just went online to check in for my flight tonight and found out that United cancelled my flight due to "crew legalities" - whatever that means. Orbitz booked me on the next available flight, which isn't until tomorrow morning at 7:00 a.m. Doh!

The good news is I get to spend another night with the wife and kids. Unfortunately, tomorrow is going to be a brutal work day since I won't get on site until 3 in the afternoon.

Candy for AppFuse

Candy for AppFuse tries to easy the adoption and usage of AppFuse 2.0 by adding some eye candy in the form of Eclipse Plug-ins. If you want the power of an integrated set of excellent J2EE tools and frameworks managed from the comfort of your IDE, give Candy for AppFuse a try.

I downloaded and tried out this plugin yesterday. Seems to work quite nicely. See Abel Muiño's blog for more details. Well done Abel!