Raible Designs

AppFuse Light 1.8 Beta Released

AppFuse Light 1.8 Beta adds CSS Framework integration, as well as support for Stripes (1.4.2) and Wicket (1.2.6). This is a beta release so we can work out some kinks before the final release.

AppFuse Light now offers 60 possible combinations for download:

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

If you have any questions about this release, please subscribe to the AppFuse user mailing list by sending a blank e-mail to [email protected].java.net. You can also post questions in a forum-like fashion using Nabble: http://appfuse.org/forums.

If you're a developer of one of the frameworks that AppFuse Light uses - I'd love a code review to make sure I'm "up to snuff" on how to use your framework. I'm also more than willing to give commit rights if you'd like to improve the implementation of your framework.

Live demos are available at:

• Spring · Spring + Ajax · Spring + Acegi
• MyFaces + Facelets
• Stripes
• Struts 1 · Struts 2
• Tapestry
• WebWork
• Wicket

Update: Based on Martin's blog post, I've added the version numbers for Stripes and Wicket (1.4.2 and 1.2.6, respectively). While the Wicket guys recommended I use Wicket 1.3.0, I was already knee deep in 1.2.6 when I read their recommendation. If 1.3.0 really is that much better than 1.2.6, it should be a pleasure to upgrade (and a good learning experience too boot!).

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.

Spring Web Flow and JSF

Keith Donald has a nice and long writeup on Spring Web Flow 1.0.3's stellar support for JSF:

One important area where our integration is growing is with the Java Server Faces (JSF) community. Beginning with Spring Web Flow 1.0.3, our JSF integration is on-par with what the Spring community expects, and delivers what JSF developers in the trenches need most. This blog will illustrate the integration enhancements to show you the difference Spring Web Flow is making for JSF developers.

One of the most interesting parts of the post is a few paragraphs down:

Basically, Web Flow solves every problem this pour soul experienced with JSF's basic navigation capabilities. As one of our leading users noted, Web Flow can be used as a complete replacement for JSF's default "forward-centric" navigation model.

It's also interesting to note that ideas from SWF could be incorporated into JSF 2.0:

I'd also like to take this opportunity to encourage those already using Spring Web Flow in a JSF environment to speak out about your experience?send me an email, leave a comment here, write an article on JSF central, tell leaders in the JSF community about your experience. Your real world experience can help influence the direction of the JSF 2.0 specification in a time where the specification lead has asked for community feedback. Interface21 has been extended an invitation from Ed Burns, the JSF specification lead, to be a part of the JSF 2.0 expert group, which is a recognition of Web Flow's contribution as an innovative JSF extension. We have accepted that invitation and are excited about helping channel whats proven to work in the area of navigation and state management on a general basis back into JSF 2.0, while continuing to chart new territory and remaining usable in any environment.

Are you using SWF with JSF? If so, have your experiences been good or bad? I'm sure Keith would love to hear about them either way.

I think it's interesting to note that both Interface21 and JBoss are doing a lot to build solutions to JSF's problems. Is there money to be made from supporting JSF? In reality, you have to like what both companies are doing: they're building solutions to overcome the shortcomings of JSF and they're contributing those solutions back to the community for free. Even cooler is the fact that both companies are trying to get their solutions into the next version of JSF. This benefits everyone as far as I'm concerned.

What about those of you using Spring Web Flow with Spring MVC or Struts? How is it working for you?

I recently integrated Spring Web Flow into my current project using the Spring Webflow Plugin. In the past, I've used SWF with Spring MVC and JSF, so the Struts 2 Plugin seemed a bit odd. I guess I'll know more once I start using it more.

This brings up a good question - do you think it's better to create a page flow (i.e. a shopping cart) without Spring Web Flow first, and then refactor? Or do you think it's easier to use SWF from the beginning? My gut feeling is to start w/o it because you may not need it. Then if you do need it, you'll understand the problems it solves. What are your thoughts?

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.

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.

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.

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!

Apache Struts 2 from Square One

Ted Husted has put together an impressive training course together for Struts 2 called Apache Struts 2 from Square One. He's released an initial version of the 127-page PDF on SourceForge.

Thanks Ted! The fact that you're contributing this hard work to the community (for free!) is amazing.

I'm teaching a 3-day training course in May that covers Spring, Hibernate, Maven 2, Ajax and AppFuse. I'm not sure if the client wants Struts 2 or Spring MVC for their web framework. If they want Struts 2, you can be sure I'll checkout Ted's course as a starting point.

Java CMS Systems

Michael Levin is at the JavaPosse Roundup this week. Today, they're discussing Java CMS Systems. I recently had an e-mail discussion with a reader regarding Java-based CMS Systems. In hopes of getting these questions answered by Michael today, here's that thread:

Original E-Mail:
OpenCMS, Magnolia CE/EE, Atleap, Alfresco, Liferay.

Magnolia EE, Day Communique, Hannon Hill, Refresh, Vertical Site.

We are leaning towards Magnolia EE since we have a load balancer and two production server, but I bet we could hack in support in the community edition.

Any comments/recommendations? -------- My response:
I'd check out Alfresco's new 2.0 WCM - just released last week. I haven't looked at many of the CMSes in a year or so, but I'm willing to bet that OpenCMS still has issues installing. I still like Drupal too and recommend it for folks just wanting a website they can edit.

In reality, my experience with CMS systems is outdated and you shouldn't consider me an authority. -------- Thanks for the lead. We actually eliminated Alfresco, b/c I thought they were more of a portal.

The reason we were leaning towards Magnolia and Vertical Site was b/c of JSR 170 (which Alfesco claims to support).

I wonder about the scalability of JCR, do have an opinion? -------- I don't have an opinion because I don't have much experience with it. It's supposed to be the JDBC of CMSs, so I imagine it's pretty scalable. However, it's pretty new, so I'm sure there will be growing pains. I know that Infoq.com uses Magnolia as their backend (and WebWork as their frontend), so obviously it scales well for them.

What are your thoughts on Java-based CMS Systems? Comments from experienced developers appreciated more than vendor pitches.

Zero Configuration in Struts 2

Struts 2 has a nifty zero configuration feature. However, it's only useful for registering actions, not for automatically registering results. In other words, you still have to use an @Result annotation to tell your action what page to dispatch to. To use default view names instead of requiring @Result, you can use the Codebehind Plugin. Also, did you know Struts 2 will autowire your Spring dependencies? It's pretty slick.

What does this all mean? It means you can write your Struts 2 application without writing any XML. Of course, you can still use XML to tweak behavior, but with these plugins enabled, you won't have to.

IMO, these plugins should be combined into a single zero configuration feature.

Here's how you can enable Struts 2's Zero Configuration feature in AppFuse 2.0:

1. Add a packageNames parameter to the "struts" filter in your web.xml:
   

   <filter>
       <filter-name>struts</filter-name>
       <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
       <init-param>
           <param-name>actionPackages</param-name>
           <param-value>com.company.newapp.webapp.action</param-value>
       </init-param>
   </filter>
   

2. Add the Codebehind Plugin as a dependency in your pom.xml:

   <dependency>
       <groupId>org.apache.struts</groupId>
       <artifactId>struts2-codebehind-plugin</artifactId>
       <version>2.0.6</version>
   </dependency>
   

3. Add a struts.codebehind.pathPrefix constant in struts.xml for your default pages directory:

   <constant name="struts.codebehind.pathPrefix" value="/WEB-INF/pages/"/>
   

That's it - now you can code away without configuring anything!

How does this compare to other web frameworks in AppFuse? Tapestry has a similar feature, but Spring MVC and JSF don't. Spring MVC still requires you create a bean definition for Controllers and JSF requires you write a chunk of XML for each managed bean. Of course, if you know how to do something similar with Spring MVC or JSF, please let me know.