Raible Designs

Maven Book and Flex Open Sourced

From Andrew Williams:

Thats right, there is a new guide out there to help all those interested in Maven (or already using it) to get the most out of their build lifecycle. It is indeed the definitive guide and will be regularly updated so it stays that way. This book is produced by my colleges at Sonatype and is a free gift to the Maven community - no registration, no catches

More documentation has never hurt an open source project. Is the book open source too?

In other kick-ass news, Flex was open sourced today. Does this mean the server is open sourced too and we can run a Flex app for free? I see the competition between OpenLaszlo and Flex heating up in the near future. Both are pretty good if you like working with XML. Does your web framework have support for OpenLaszlo and Flex?

What web framework are you using with AppFuse?

As part of my upcoming Comparing Java Web Frameworks talk, I'd like to show some statistics of web framework usage in AppFuse. Please vote for the one you're using by clicking on the link below. I'm mostly looking for current AppFuse users. By that, I mean folks that have used 1.x or 2.x on a project in the last 6 months, or plan on using it in the next month or two.

You'll need to create an account and login to vote. To do this, go to View > Account > Sign Up (after clicking on the link below).

• http://appfuse.org/pages/viewpage.action?pageId=986

I'll compile the results of this poll on Friday morning (April 27th), so you have until then for your vote to be counted!

On a related note, if anyone knows how to get the monthly posting statistics from Spring MVC's forums, I'd love to hear about it. My "mailing list traffic" slide has excluded them for the past couple of years because I've been unable to get a count of monthly postings.

NOTE: If you vote by adding a comment to this entry, it won't be counted.

Update: Thanks to the 64 of you that voted. Here's the results of the poll:

As I said last time, I find the results interesting because AppFuse lowers the barriers and reduces the learning curve for all of these frameworks.

Equinox (a.k.a. AppFuse Light) 1.7.1 Released!

Equinox 1.7.1 contains a number of dependency updates, and not much else. This will be the last release with the Equinox name. This project is changing its name to AppFuse Light and will be referred to by that name going forward. The project will be moving its source code to http://appfuse-light.dev.java.net. The equinox.dev.java.net project will remain because Cool URIs don't change. In addition to the name change, I'd like to try to merge the AppFuse and Equinox user communities. Since the technologies are so similar, and AppFuse 2.x will use some of Equinox's Ant scripts, it makes sense to bring these projects closer together.

In AppFuse Light 1.8, I plan on adding support for Stripes and Wicket as well as integrating the CSS Framework (like AppFuse uses).

50 possible combinations are available for download:

• Web Frameworks: JSF (MyFaces), Spring MVC (with Ajax, Acegi Security, JSP, FreeMarker or Velocity), Struts 1.x, Struts 2.x, Tapestry, WebWork
• Persistence Frameworks: Hibernate, iBATIS, JDO (JPOX), OJB, Spring JDBC

All of the frameworks used in Equinox, as well as most of its build/test system is explained in Spring Live. Going forward, documentation will be put on the AppFuse site.

A summary of the changes in this release are below:

• Removed custom JavaScript and CSS for MyFaces Tomahawk's
• Dependent packages upgraded:
  • Ajax4JSF 1.0.6
  • Cargo 0.9
  • Commons Collections 3.2
  • Commons DBCP 1.2.2
  • Commons Lang 2.3
  • Commons Validator 1.3.1
  • DWR 2.0 RC2
  • FreeMarker 2.3.9
  • JPOX 1.1.7
  • JUnit 3.8.2
  • Hibernate 3.2.1
  • iBATIS 2.3.0
  • MyFaces and Tomahawk 1.1.5
  • Spring 2.0.4
  • Spring Modules Validation 0.8
  • Struts 2.0.6
  • Tapestry 4.1.1
  • Velocity 1.5
  • Velocity Tools 1.3
  • WebWork 2.2.5

For more information about installing the various options, see the README.txt file. Live demos (thanks to Contegix!) are available at:

• Spring · Spring + Ajax · Spring + Acegi
• JSF + Facelets
• Struts 1 · Struts 2
• Tapestry
• WebWork

If you have any questions, please read the comments from the 1.7 release or ask them on the AppFuse mailing list.

Acegi Security adds OpenID support to its sandbox

From the Acegi Security mailing list:

Thanks to the efforts of Robin Bramley; we now have a first draft of OpenID support in the sandbox. The code is mostly as-is from when Robin submitted sent it to me. I've done all the standard jalopy formatting of the code so it blends in and has the proper file headers.

I don't know how much this will help folks developing intranet applications, but it's pretty cool for those doing otherwise. Anyone want to take a stab getting OpenID working with Roller? It uses Acegi and supports SSO, so hopefully it won't be too difficult.

See Timothy M. O'Brien's writeup as well as Ray Krueger's for more information.

OSCache vs. EhCache for Hibernate's 2nd Level Cache

Hibernate has a number of options for configuring its second level cache. For more information on configuring this, you might want to read John Ferguson Smart's article titled Speed Up Your Hibernate Applications with Second-Level Caching.

Up until today, I thought EhCache was the default cache provider, but apparently not anymore. From Hibernate's documentation:

Note that versions prior to 3.2 defaulted to use EhCache as the default cache provider; that is no longer the case as of 3.2.

So what's the default now? It can't be Hashtable since that's not for production use. I doubt it's OSCache since OSCache can't even get its patches into Hibernate. Looking through the release notes, I found out it's NoCacheProvider - seemingly because of an issue with EhCache:

Due to the upgrade to EhCache1.2 and its new non-singleton cache setup, we should no longer default the cache provider to be ehcache. Instead, default to NoCacheProvider.

That's reasonable I guess. EhCache added support for distributed caching in 1.2. It's a shame they didn't maintain backwards compatibility or they'd still be the default caching provider. Regardless, it doesn't matter who the default caching provider is because it's very easy to change it. Here's how it's configured on one of my projects:

<bean id="sessionFactory" 
    class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="configLocation" value="classpath:hibernate.cfg.xml"/>
    <property name="hibernateProperties">
        <value>
            hibernate.dialect=${hibernate.dialect}
            hibernate.query.substitutions=true 'Y', false 'N'
            hibernate.cache.use_second_level_cache=true
            hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider
        </value>
    </property>
</bean>

Of course, you can also configure it directly in hibernate.cfg.xml or a hibernate.properties file.

This leads me to the reason for this post:

What is the best 2nd level (clustered) cache to use for Hibernate?
I'm sure some folks will say Coherence, so let's narrow the question to what's the best open source option?

I've used OSCache in the past. It worked well, but it was kind of annoying that I had to patch Hibernate to make it work. The Hibernate folks say it's OSCache's fault, the OSCache guys say it's Hibernate's fault - so this issue will likely never get resolved. So what about EhCache? I don't know, I've only used it in a single JVM environment and haven't tried it in a clustered environment. Is there anyone using Hibernate + EhCache in production that can verify its effectiveness?

Of the options listed in Hibernate's documentation, the only other options seem to be JBoss TreeCache and SwarmCache. You can quickly eliminate SwarmCache since it never made it past 1.0 RC2 in October of 2003.

That leaves JBoss TreeCache, EhCache and OSCache as choices for a clusterable 2nd-level cache. OSCache is an invalidating cache, which definitely works - but might not work as you expect it to. JBoss Cache only seems to allow a replicated cache which also works. EhCache seems to support both. I don't know if invalidating or replicating is better, but I imagine replicating can get quite chatty if you're dealing with large amounts of data.

But wait - is there another open source option? According to Terracotta's CTO, Terracotta is much faster than JBoss Cache. However, if you read about it on DZone, you'll see that JBoss Cache has no "official" benchmarks.

So what's a developer to do? My current client likes OSCache, but I'm leaning towards EhCache. Which would you recommend?

Of course, if Coherence is only $1K per CPU, maybe that's the obvious choice? Unfortunately, I couldn't find their pricing using Google.

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!

AppFuse 2.0 M4 Released

The AppFuse Team is pleased to announce the release of AppFuse 2.0 M4! This release marks a milestone in the usability of AppFuse 2.x. A lot of folks (including myself) have been using AppFuse 2.0 on projects and have fixed quite a few issues. In addition to polishing the tutorials, we've fixed a fair amount of i18n bugs and packaging issues with modular archetypes.

We were hoping to get AMP's code generation and XFire integrated in M4, but were it's going to have to wait until M5.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide.

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ and join the user mailing list if you have any questions. The Maven Reference Guide has a map of Ant » Maven commands.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

• Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
• Java 5 for Development (Java 1.4 for deployment using the Retrotranslator Plugin)

For more information, please see the 2.0 M4 Release Notes. To see how AppFuse 2.x works, please see the video demos.

Comments and issues should be sent to the mailing list.

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. We also greatly appreciate the help from our sponsors, particularly Atlassian, Cenqua, Contegix, JetBrains, Java.net and KGBInternet. Without them, working on this project wouldn't be nearly as much fun.

Comparing IDEs and Issue Trackers

A couple of good comparison articles came out today:

• What issue tracking system is best for you? A review of Bugzilla, Trac, and JIRA by John Ferguson Smart
• Eclipse, NetBeans, and IntelliJ: Assessing the Survivors of the Java IDE Wars by Jacek Furmankiewicz

Issue Tracking Systems Conclusion
These products reviewed are among the most widely used in the Java community. Bugzilla, with an uninspiring user interface, is rich in features, but undeniably cumbersome to install and to maintain. Trac is a good, lightweight solution that should be seriously considered by any development team using Subversion. JIRA is a solid, powerful solution, providing almost all of the features of Bugzilla, and more, in an eminently more usable (and more productive) form ? but at a cost.

I agree with John's conclusion - Bugzilla was cool 5 years ago, but there's much better systems now. If you're running an open source project, it's a no-brainer to use JIRA. If you're working at a company and want to use an open-source solution, Trac works well.

IDE Wars Conclusion
For enterprise development, I'd say IDEA wins out with its rich support for both J2EE and Java EE 5, followed closely by NetBeans (which also does an impressive job here), and last is Eclipse/MyEclipse (mostly due to their current lack of support for Java EE 5).

I agree with Jacek as well. I've been using IDEA almost exclusively for the last 6 months - ever since I started to convert AppFuse to use Maven 2. Eclipse's support for sub-projects has been pretty pitiful and IDEA has *much* better support for web development - particularly JavaScript and CSS.

Lately, I've found myself advocating IDEA and JIRA to clients more and more. A few years ago it was Bugzilla and Eclipse. However, these IDEA and JIRA (as well as Confluence and FishEye) are so cheap in the relative scheme of things - I think they actually pay for themselves these days.

Disclaimer: I use IDEA, Confluence and JIRA on a daily basis. I use Trac and Eclipse on a weekly basis. I paid for my original IDEA license out of my own pocket, but I received my most recent license for speaking at Denver's JUG. Confluence and JIRA are provided free of charge by Atlassian for AppFuse.