Raible Designs

AppFuse 3.5 Released!

2015-02-20T09:08:53-07:00

The AppFuse Team is pleased to announce the release of AppFuse 3.5. This release contains a number of improvements.

XML reduced by 8x in projects generated with AppFuse
CRUD generation support for Wicket, as well as AppFuse Light archetypes (Spring Security, Spring FreeMarker and Stripes)
Upgraded Tapestry to 5.4
Integrated Spring IO Platform for dependency management
Refactored unit tests to use JUnit 4
Renamed maven-warpath-plugin to warpath-maven-plugin
Upgraded to jWebUnit 3 for AppFuse Light integration tests
Updated all AppFuse Light modules to be up-to-date

For more details on specific changes see the release notes.

What is AppFuse?
AppFuse is a full-stack framework for building web applications on the JVM. It was originally developed to eliminate the ramp-up time when building new web applications. Over the years, it has matured into a very testable and secure system for creating Java-based webapps.

Demos for this release can be viewed at http://demo.appfuse.org. Please see the QuickStart Guide to get started with this release.

If you have questions about AppFuse, please read the FAQ or join the user mailing list. If you find any issues, please report them on the users mailing list. You can also post them to Stack Overflow with the "appfuse" tag.

Thanks to everyone for their help contributing patches, writing documentation and participating on the mailing lists.

We greatly appreciate the help from our sponsors, particularly Atlassian, Contegix, and JetBrains. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project.

Comparing JVM Web Frameworks at vJUG

2014-02-06T10:54:17-07:00

A couple months ago, I was invited to speak at Virtual JUG - an online-only Java User Group organized by the ZeroTurnaround folks. They chose my Comparing JVM Web Frameworks presentation and we agreed I'd speak yesterday morning. They used a combination of Google Hangouts, live streaming on YouTube and IRC to facilitate the meeting. It all went pretty smoothly and produced a comfortable speaking environment. To practice for vJUG, I delivered the same talk on Tuesday night at the Denver Open Source Users Group.

The last time I delivered this talk was at Devoxx France in March 2013. I didn't change any of the format this time, keeping with referencing the Paradox of Choice and encouraging people to define constraints to help them make their decision. I did add a few new slides regarding RebelLabs' Curious Coder’s Java Web Frameworks Comparison: Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF and The 2014 Decision Maker’s Guide to Java Web Frameworks.

I also updated all the pretty graphs (which may or may not have any significance) with the latest stats from Dice.com, LinkedIn, StackOverflow and respective mailing lists. Significant changes I found compared to one year ago:

Job Listings on Dice.com
- Play Framework job listings increased almost 4x
- Tapestry jobs are 1/3 of what they were a year ago
- Wicket jobs are 1/2 of what they were a year ago
- JavaScript framework jobs are up quite a bit: Ember.js up ~300%, AngularJS up 900%, Backbone up 160%
LinkedIn Skills
- Rails down ~30%
- Grails up 25%
- Play Framework up 200%
- Spring Roo up 40%
- Ember.js up 300%
- AngularJS up 840%
- Backbone up 200%

As you can tell from these findings, AngularJS has gained quite a bit of mindshare in the last year. There's a lot of companies looking for JavaScript skills and quite a few folks have added JavaScript frameworks to their LinkedIn profiles.

You can watch the recording on YouTube or click play in the embedded video below.

You can also quickly browse the slide deck below, download the PDF or view it on SlideShare.

Thanks to all the folks who attended these talks. And thanks to @dosug and @virtualjug for giving me the opportunity to speak.

Switching AppFuse from MyFaces to PrimeFaces

2013-02-06T12:19:34-07:00

When describing my bias against JSF back in November, I wrote:

... there's a lot of folks praising JSF 2 (and PrimeFaces moreso). That's why I'll be integrating it (or merging your pull request) into the 2.3 release of AppFuse. Since PrimeFaces contains a Bootstrap theme, I hope this is a pleasant experience and my overall opinion of JSF improves.

Shortly after the AppFuse 2.2.1 release in December, Gilberto Andrade contributed a sample project that used Mojarra (the JSF RI) and PrimeFaces instead of MyFaces and its Tomahawk components. Last week, I spent a few hours integrating Gilberto's changes into AppFuse's master branch. You can see all the changes I made (which include a Jetty plugin upgrade and some cleanup) in this Crucible review. Feel free to leave comments on ask questions in the review itself.

The first thing I noticed when integrating PrimeFaces is you have to add a custom repository in order to get its artifacts via Maven.

<repositories>
    <repository>
        <id>prime-repo</id>
        <name>Prime Repo</name>
        <url>http://repository.primefaces.org</url>
    </repository>
</repositories>

This is unfortunate since all of AppFuse's other dependencies can be found in Maven Central. It means that if you're using a JSF archetype, the PrimeFaces repo will be checked for artifacts first, causing an unnecessary slowdown in artifact resolution. I hope the PrimeFaces developers fix this soon.

While integrating these two frameworks, I ran into a number of issues.

An IllegalStateException on startup when using "mvn jetty:run"
The first issue I encountered was that I was unable to run the app in Jetty. It worked fine in Tomcat but I got the following error in Jetty:

2013-01-31 22:28:07.683:WARN:/:unavailable
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:951)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:316)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:302)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:492)
at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:312)

I found the fix for this on Stack Overflow and added the following listener to my web.xml to solve it.

<listener>
    <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

Conditionally rendering a button disables its click-ability
The next thing I noticed was the Delete button didn't work when editing a user. It was hidden correctly when adding a user, but clicking on it to delete a user simply refreshes the page. Below is the code I used successfully with MyFaces. For some reason, this doesn't work with PrimeFaces.

<c:if test="${not empty userForm.user.id}">
<h:commandButton value="#{text['button.delete']}" action="#{userForm.delete}"
    styleClass="btn" onclick="return confirmMessage(msgDelConfirm)"/>
</c:if>

I also tried the following, but no dice. This is currently an open issue.

<h:commandButton rendered="${not empty userForm.user.id}" value="#{text['button.delete']}" 
    action="#{userForm.delete}" styleClass="btn" onclick="return confirmMessage(msgDelConfirm)"/>

The PrimeFaces Bootstrap theme 404s on some images
After integrating PrimeFaces' Bootstrap theme, the following error shows up in server logs.

[INFO] [talledLocalContainer] Feb 02, 2013 10:40:25 PM com.sun.faces.application.resource.ResourceHandlerImpl logMissingResource
[WARNING] [talledLocalContainer] WARNING: JSF1064: Unable to find or serve resource, images/ui-bg_highlight-hard_70_000000_1x100.png, from library, primefaces-bootstrap.

This seems to have happened before in previous releases and is currently an open issue.

Canoo WebTest doesn't work with fileUpload nor to set checkbox values
We use Canoo WebTest to run integration tests on the UI in AppFuse. For some reason, performing file uploads and setting checkbox values works fine with MyFaces/Tomahawk, but not with Mojarra/PrimeFaces. I'm not sure if this is caused by the JSF core or the component library, but it remains an open issue. For now, I've just commented out the parts of tests that used to do this.

On a related note, getting the real path of a resource from the ServletContext worked fine before the switch, but results in a null value now.

String uploadDir = getServletContext().getRealPath("/resources") + "/" + request.getRemoteUser() + "/";

PrimeFaces resources served up at /javax.faces.resource/* not found
While I didn't have problems with this in AppFuse, I did encounter it in AppFuse Light. I don't know why there was a difference between the two, but it turned out to be caused by the UrlRewriteFilter and my desire for extensionless URLs. The outbound-rule to strip .xhtml from URLs was the culprit. Adding a condition to it solved the problem. Yeah, the condition seems backwards, but it works.

<outbound-rule match-type="regex">
    <condition type="query-string" operator="equal">ln=primefaces</condition>
    <from>^(.*)\.xhtml(\?.*)?$</from>
    <to last="false">$1$2</to>
</outbound-rule>

Summary
The initial switch to Mojarra/PrimeFaces was pretty easy thanks to Gilberto's sample project. However, the small issues encountered after that turned out to be quite frustrating and you can see that several are still not fixed. I guess it just goes to show that not all web frameworks are perfect. Hopefully we'll get these minor issues fixed before the next release. In the meantime, you can checkout the updated demos for AppFuse JSF and AppFuse Light JSF.

Why the bias against JSF?

2012-11-08T09:24:27-07:00

In my last post about InfoQ's Top 20 Web Frameworks for the JVM, I received a thought-provoking comment from henk53:

There is one little thing that does bother me in those presentations, and that's your fairly obvious bias against JSF.
...
If you are presenting yourself as, more or less, an authority on comparing web frameworks, then having a fairly obvious biased against one of them is just peculiar. I, all of my team, and various clients distrust your ranking of JSF. We do look at your data if the choice is between other frameworks, but as soon as JSF comes into the picture we just look elsewhere.

I'm not really sure where this bias comes from. Yes, JSF 1.0 sucked and 1.2 was only marginally better, but 2.0 is really cool and productive and there are SUPERB component and utility libraries now like PrimeFaces and OmniFaces. As a researcher of this topic I think you should keep up the date and not stick to some old grudge.

This is true, I am biased against JSF. It all started with my first JSF experience back in August 2004. If you remember correctly, 2004 was a big year: JSF 1.0, Spring 1.0 and Flex 1.0 were all released. The "AJAX" term was coined in early 2005.

By 2007 and 2008, JSF still hadn't gotten any better. In late 2009, JSF 2.0 was released and I upgraded in March 2011. As you can see from the aforementioned post, I ran into quite a few issues upgrading. JSF was also the hardest one to get working with extension-less URLs.

Most of my issues with JSF come from having maintained an application built with it since 2004. If I were to start a new application without any legacy migration issues, I imagine it wouldn't be as difficult. However, if you compare it to Struts 2 and Spring MVC, I've had little-to-no issues upgrading those applications over the years.

Also, I'm not just biased against JSF, but most component-based web frameworks. Just ask the Tapestry and Wicket folks. They've felt my criticisms over the years. My reason for preferring request-based frameworks like Struts 2/Spring MVC and Grails/Play has been because I've never seen the appeal in component-based frameworks. Often I've found that their components are just widgets that you can get from any decent JavaScript framework. And chances are that JavaScript framework can work with any web framework. Also, I've worked on a lot of high-traffic web applications that require statelessness for scalability.

I see the value in component-based frameworks, I just don't think components should be authored on the server-side. Most of the Java-based component frameworks require 2+ files for components (one for the component, one for the view, possibly one for the config). I love GWT's component concept in that you can just extract a class and re-use it. With JS frameworks, you can often just include a script. These days, when I think of good component-based frameworks, I think of jQuery UI and Twitter Bootstrap.

All that being said, there's a lot of folks praising JSF 2 (and PrimeFaces moreso). That's why I'll be integrating it (or merging your pull request) into the 2.3 release of AppFuse. Since PrimeFaces contains a Bootstrap theme, I hope this is a pleasant experience and my overall opinion of JSF improves.

In other component-based frameworks in AppFuse news, Tapestry 5 has gotten really fast in the last year. I imagine this is because we have a Tapestry expert, Serge Eby, working on it. And we're planning on adding Wicket in the 2.3 release.

So even though I prefer request-based frameworks with REST support and Bootstrap, that doesn't mean everyone does. I'll do my best to be less-biased in the future. However, please remember that my view on web frameworks is as a developer, not an analyst. And aren't developers supposed to be opinionated?

Hyperproductive JSF 2.0 with Ed Burns at Jazoon

2011-06-23T04:53:10-06:00

This morning, I attended Ed Burn's Talk on Hyperproductive JSF 2.0 at Jazoon. As you might know, I've been a critic of JSF for many years. However, it is one of the most used Java web frameworks, so I was hoping to learn how it's improved in the latest version. Below are my notes from Ed's presentation.

Ed's Plan for our Time Investment:

Define a productive development environment
JSF for greenfield and brownfield projects
List the top 9 productivity killers with JSF projects and solutions

"I am always doing that which I cannot do, in order that I may learn how to do it." -- Pablo Picasso

Software is an executable representation of knowledge, a byproduct of learning how to solve a problem. Knowledge is something that changes as more information comes in. A productive environment makes it as easy as possible to learn how to solve a problem. Learning is an iterative process. Early iterations don't need to be optimal. Later iterations do ... and they need to be maintainable. First is the hardest. Fast iterations are they key. Spring Roo and Play are examples of frameworks that make the first iteration very fast.

You should use a tool to jumpstart JSF development: copy from an old project, use a Maven archetype or use your IDE. With greenfield development, you don't have to bother learning the byproduct of other people's learning. It's a great opportunity to pad your resume with the latest hot technologies. With brownfield development, it's vitally important to understand the existing solution and hidden assumptions. You're also much more constrained in your technology choices. If you want to change, you'll need to come up with a migration strategy, which can be difficult. JSF works well for both because it's not just a runtime framework, it's also a conceptual framework. You need to understand how your framework handles data conversion, validation, page flow, persistence integration, I18N, L10N, A11Y, Web standards and user friendliness.

Top 9 JSF Productivity Killers:

Time wasting deployment step
The perils of "there's more than one way to do it"
Lengthy and painful developer on-boarding process
Misused logging and misunderstood error messages
Phantoms
Under-utilized developer tools
Premature optimization
Difficulty in doing TDD
Lack of an app framework

Time wasting deployment step
ZeroTurnaround solves this problem with JRebel, but there's other ways to do it. Some of the killers of flow state: 1) one large war file, 2) underutilizing dynamic language features, 3) complex server environment and 4) build process is redoing work unnecessarily. To stop the time wasting deployment step, the most important things you can do are as follows:

Configure your IDE correctly. In Eclipse, compile directly into WEB-INF/classes and use continuous compilation. With NetBeans, use GlassFish.
Don't do control-flow programming in XML.

Ed then showed a simple demo that showed how you can use Groovy to create a JSF UI Component. He also mentioned that Groovy can be used to author any JSF artifact. The benefit of this is you can simply edit and save a .groovy file without having to recompile or redeploy. Unfortunately, using Groovy didn't eliminate the XML syntax for pages or the XML for defining UI components.

The perils of "there's more than one way to do it"
JSF is very flexible, but flexibility is, more often than not, abused. There's a lack of convention for common things (e.g. master-detail, JSF concepts like converter, validator, etc.). The best way to fix this is to establish the norms for a project and stick with them. For example, Neil Griffin has a good blog entry for the different kind of managed beans you can create. Develop recommendations like Neil's and use them on all your projects.

Lengthy developer on-boarding process
Stick with standards when possible (at least have a common project description and build system across projects). Be committed to periodic cleanup cycles, including documenting for re-use. Pick one JSF component library and stick with it. Support for mixing and switching component libraries has improved with JSF 2, but it's still recommended you use only one.

Misused logging and misunderstood error messages
JSF is notorious for cryptic error messages and very long stack traces. It's still a problem, but the JSF Team is still working on improving them. Good tip: use the <ui:debug> tag. Its recordStateSize="true" attribute can be especially useful. If you're using PrimeFaces, add trace=true to request URLs.

Phantoms
Phantoms is when running code is not the same as the code you are modifying or wrong version of library gets picked up. You should have the capability to hit breakpoints anywhere in your entire software stack, including core Java sources. This is one of the most useful things about open source software. Solutions to phantoms: 1) put a timestamp on every redeploy and have the timestamp appear in the system log 2) write the running library stack to the system log (each library and version being used) and make it easy to compare one developer's runtime stack with another's 3) consider doing all work in tightly controlled VMs (checkout the VM at the beginning of the day, do your work, commit your changes and throw your VM away at the end of the day).

Under-utilizing developer tools
Make sure everyone has the fastest machines available and as much screen real estate as desired. Hardware is much cheaper than developer time. Another tip is to use Hudson as your butler. It's not just the team CI server. In other words, take advantage of automation wherever you can.

Premature Optimization
Keep in mind the trade-offs between readability and performance. When using frameworks such as JSF, don't try to outsmart the implementation. Rather, use the framework as intended and use open-source contributions to treat performance problems. Example, EL expressions got a lot faster between EE5 and EE6. If you spent time trying to optimize EL expressions, you might've been wasting your time.

Difficulty in doing TDD
Try to figure out why TDD is difficult in your company. For JSF, strongly consider JBoss's JSFUnit. Write your testcases to extend from Cactus ServletTestCase and leverage HtmlUnit (JSFUnit does this for you).

Lack of an app framework
Create common components: login panel, CRUD components, etc. If you don't have an app framework, build one over time.

Conclusion
This was an interesting talk by Ed. The dynamics of the room where a bit interesting. Jazoon is held in a movie theater, much like Devoxx. However, it appears there's a spotlight on the speaker that makes it very difficult to see the audience. I don't remember having this problem at Devoxx. Ed asked the audience quite a few questions, but it seemed he had a lot of difficulty in seeing if folks raised their hands. This made for some periods of awkward silence.

Personally, I was hoping to learn some new whizbang tips about JSF that I was not aware of. Unfortunately, I didn't learn anything new and wasn't that impressed with the Groovy demo.

I think Ed's tips about things outside of JSF were good, especially buying developers good hardware. I've seen many companies, including my current client, skimp on developer hardware and cause developer frustration because of it. I think it's great when companies provide developers top-of-the-line hardware and eliminate frustration over CPU and memory resources. LinkedIn and Time Warner Cable both provide their developers with Mac Pros and MacBook Pros as well as huge monitors. IMO, this is one of the best benefits you can provide your engineers.

Upgrading to JSF 2

2011-03-07T13:24:53-07:00

Last week, I spent a few hours upgrading AppFuse from JSF 1.2 to JSF 2.0. In reality, I upgraded from MyFaces 1.2.7 to 2.0.4, but all JSF implementations should be the same, right? All in all, it was a pretty easy upgrade with a few minor AppFuse-specific things. My goal in upgrading was to do the bare minimum to get things working and to leave integration of JSF 2 features for a later date.

In addition to upgrading MyFaces, I had to upgrade Tomahawk by changing the dependency's artifactId to tomahawk20. I was also able to remove the following listener from my web.xml:

<listener>
    <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
<listener>

After that, I discovered that MyFaces uses a new URI (/javax.faces.resource/) for serving up some of its resource files. I kindly asked Spring Security to ignore these requests by adding the following to my security.xml file.

<intercept-url pattern="/javax.faces.resource/**" filters="none"/>

Since JSF 2 includes Facelets by default, I tried removing Facelets as a dependency. After doing this, I received the following error:

ERROR [308855416@qtp-120902214-7] ViewHandlerWrapper.fillChain(158) | Error instantiation parent Faces ViewHandler
java.lang.ClassNotFoundException: com.sun.facelets.FaceletViewHandler
        at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:401)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
        at org.ajax4jsf.framework.ViewHandlerWrapper.fillChain(ViewHandlerWrapper.java:144)
        at org.ajax4jsf.framework.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:68)
        at org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:179)
        at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:113)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)

Figuring this was caused by the following element in my web.xml ...

<context-param>
    <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
    <param-value>com.sun.facelets.FaceletViewHandler</param-value>
</context-param>

... I removed it and tried again. This time I received a NoClassDefFoundError:

java.lang.NoClassDefFoundError: com/sun/facelets/tag/TagHandler
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:392)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:247)
        at org.apache.myfaces.shared_impl.util.ClassUtils.classForName(ClassUtils.java:184)
        at org.apache.myfaces.view.facelets.util.ReflectionUtil.forName(ReflectionUtil.java:67)

Since everything seemed to work with Facelets in the classpath, I decided to save this headache for a later date. I entered two issues in AppFuse's JIRA, one for removing Facelets and one for replacing Ajax4JSF with RichFaces.

The next issue I encountered was redirecting from AppFuse's password hint page. The navigation-rule for this page is as follows:

<navigation-rule>
    <from-view-id>/passwordHint.xhtml</from-view-id>
    <navigation-case>
        <from-outcome>success</from-outcome>
        <to-view-id>/login</to-view-id>
        <redirect/>
    </navigation-case>
</navigation-rule>

With JSF 2.0, the rule changes the URL to /login.xhtml when redirecting (where it was left as /login with 1.2) and it was caught by the security setting in my web.xml that prevents users from viewing raw templates.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Protect XHTML Templates</web-resource-name>
        <url-pattern>*.xhtml</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>

To solve this issue, I had to make a couple of changes:

Comment out the security-constraint in web.xml and move it to Spring Security's security.xml file.
```
<intercept-url pattern="/**/*.xhtml" access="ROLE_NOBODY"/>
```
Add a rule to urlrewrite.xml that redirects back to login (since login.xhtml doesn't exist and I'm using extensionless URLs).
```
<rule match-type="regex">
    <from>^/login.xhtml$</from>
    <to type="redirect">%{context-path}/login</to>
</rule>
```

After getting the Password Hint feature passing in the browser, I tried running the integration tests (powered by Canoo WebTest). The Password Hint test kept failing with the following error:

[ERROR] /Users/mraible/dev/appfuse/web/jsf/src/test/resources/web-tests.xml:51: JavaScript error loading
page http://localhost:9876/appfuse-jsf-2.1.0-SNAPSHOT/passwordHint?username=admin: syntax error (http://
localhost:9876/appfuse-jsf-2.1.0-SNAPSHOT/javax.faces.resource/oamSubmit.js.jsf?ln=org.apache.myfaces#122)

Figuring this was caused by my hack to submit the form when the page was loaded, I turned to Pretty Faces, which allows you to call a method directly from a URL. After adding the Pretty Faces dependencies to my pom.xml, I created a src/main/webapp/WEB-INF/pretty-config.xml file with the following XML:

<url-mapping>
    <pattern value="/editProfile"/>
    <view-id value="/userForm.jsf"/>
    <action>#{userForm.edit}</action>
</url-mapping>

<url-mapping>
    <pattern value="/passwordHint/#{username}"/>
    <view-id value="/passwordHint.jsf"/>
    <action>#{passwordHint.execute}</action>
</url-mapping>

This allowed me to remove both editProfile.xhtml and passwordHint.xhtml, both of which simply auto-submitted forms.

At this point, I figured I'd be good to go and ran my integration tests again. The first thing I discovered was that ".jsf" was being tacked onto my pretty URL, most likely by the UrlRewriteFilter. Adding the following to my PasswordHint.java class solved this.

if (username.endsWith(".jsf")) {
    username = username.substring(0, username.indexOf(".jsf"));
}

The next thing was a cryptic error that took me a while to figure out.

DEBUG [1152467051@qtp-144702232-0] PasswordHint.execute(38) | Processing Password Hint...
2011-03-05 05:48:52.471:WARN::/passwordHint/admin
com.ocpsoft.pretty.PrettyException: Exception occurred while processing <:#{passwordHint.execute}> null
        at com.ocpsoft.pretty.faces.beans.ActionExecutor.executeActions(ActionExecutor.java:71)
        at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.processEvent(PrettyPhaseListener.java:214)
        at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.afterPhase(PrettyPhaseListener.java:108)
        at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)

Digging into the bowels of MyFaces, I discovered a class was looking for a viewId with an extension and no view-id was being set. Adding the following to the top of my execute() method solved this.

getFacesContext().getViewRoot().setViewId("/passwordHint.xhtml");

After making this change, all AppFuse's integration tests are passing and the upgrade seems complete. The only other issues I encountered were logging-related. The first is an error about Tomahawk that doesn't seem to affect anything.

Mar 5, 2011 6:44:01 AM com.sun.facelets.compiler.TagLibraryConfig loadImplicit
SEVERE: Error Loading Library: jar:file:/Users/mraible/.m2/repository/org/apache/myfaces/tomahawk/tomahawk20/1.1.10/tomahawk20-1.1.10.jar!/META-INF/tomahawk.taglib.xml
java.io.IOException: Error parsing [jar:file:/Users/mraible/.m2/repository/org/apache/myfaces/tomahawk/tomahawk20/1.1.10/tomahawk20-1.1.10.jar!/META-INF/tomahawk.taglib.xml]: 
        at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.java:410)
        at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryConfig.java:431)
        at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
        at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)

The second is excessive logging from MyFaces. As far as I can tell, this is because MyFaces switched to java.util.logging instead of commons logging. With all the frameworks that AppFuse leverages, I think it has all the logging frameworks in its classpath now. I was hoping to fix this by posting a message to the mailing list, but haven't received a reply yet.

[WARNING] [talledLocalContainer] Mar 5, 2011 6:50:25 AM org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider newInstance
[WARNING] [talledLocalContainer] INFO: Creating instance of org.appfuse.webapp.action.BasePage
[WARNING] [talledLocalContainer] Mar 5, 2011 6:50:25 AM org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider destroyInstance
[WARNING] [talledLocalContainer] INFO: Destroy instance of org.appfuse.webapp.action.BasePage

After successfully upgrading AppFuse, I turned to AppFuse Light, where things were much easier.

Now that AppFuse uses JSF 2, I hope to start leveraging some of its new features. If you're yearning to get started with them today, I invite you to grab the source and start integrating them yourself.

Implementing Extensionless URLs with Tapestry, Spring MVC, Struts 2 and JSF

2011-02-10T16:53:27-07:00

For the past couple of weeks, I've spent several evening hours implementing extensionless URLs in AppFuse. I've been wanting to do this ever since I wrote about how to do it a few years ago. This article details my experience and will hopefully help others implement this feature in their webapps.

First of all, I used the UrlRewriteFilter, one of my favorite Java open source projects. Then I followed a pattern I found in Spring's "mvc-basic" sample app from MVC Simplifications in Spring 3.0. The app has since changed (because SpringSource integrated UrlRewriteFilter-type functionality in Spring MVC), but the pattern was basically path-matching instead of extension-mapping. That is, the "dispatcher" for the web framework was mapped to /app/* instead of *.html.

Prior to the move to extensionless URLs, AppFuse used *.html for its mapping and this seemed to cause users problems when they wanted to serve up static HTML files. To begin with, I removed all extensions from URLs in tests (Canoo WebTest is used for testing the UI). I also did this for any links in the view pages and redirects in the Java code. This provided a decent foundation to verify my changes worked. Below are details about each framework I did this for, starting with the one that was easiest and moving to hardest.

Tapestry 5
Tapestry was by far the easiest to integrate extensionless URLs into. This is because it's a native feature of the framework and was already integrated as part of Serge Eby's Tapestry 5 implementation. In the end, the only things I had to do where 1) add a couple entries for CXF (mapped to /services/*) and DWR (/dwr/*) to my urlrewrite.xml and 2) change the UrlRewriteFilter so it was only mapped to REQUEST instead of both REQUEST and FORWARD. Below are the mappings I added for CXF and DWR.

<urlrewrite default-match-type="wildcard">
    ...
    <rule>
        <from>/dwr/**</from>
        <to>/dwr/$1</to>
    </rule>
    <rule>
        <from>/services/**</from>
        <to>/services/$1</to>
    </rule>
</urlrewrite>

Spring MVC
I had a fair amount of experience with Spring MVC and extensionless URLs. Both the Spring MVC applications we developed last year at Time Warner Cable used them. To change from a *.html mapping to /app/* was pretty easy and involved removing more code than I added. Previously, I had a StaticFilter that looked for HTML files and if it didn't find them, it dispatched to Spring's DispatcherServlet. I was able to remove this class and make the web.xml file quite a bit cleaner.

To make UrlRewriteFilter and Spring Security play well together, I had to move the securityFilter so it came after the rewriteFilter and add an INCLUDE dispatcher so included JSPs would have a security context available to them.

<filter-mapping>
    <filter-name>rewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>securityFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
</filter-mapping>

The only other things I had to change were security.xml and dispatcher-servlet.xml to remove the .html extensions. The urlrewrite.xml file was fairly straightforward. I used the following at the bottom as a catch-all for dispatching to Spring MVC.

<rule>
    <from>/**</from>
    <to>/app/$1</to>
</rule>
<outbound-rule>
    <from>/app/**</from>
    <to>/$1</to>
</outbound-rule>

Then I added a number of other rules for j_security_check, DWR, CXF and static assets (/images, /scripts, /styles, /favicon.ico). You can view the current urlrewrite.xml in FishEye. The only major issue I ran into was that Spring Security recorded protected URLs as /app/URL so I had to add a rule to redirect when this happened after logging in.

<rule>
    <from>/app/**</from>
    <to last="true" type="redirect">%{context-path}/$1</to>
</rule>

Struts 2
Using extensionless URLs with Struts 2 is likely pretty easy thanks to the Convention Plugin. Even though this plugin is included in AppFuse, it's not configured with the proper constants and I have struts.convention.action.disableScanning=true in struts.xml. It looks like I had to do this when I upgraded from Struts 2.0.x to Struts 2.1.6. It's true AppFuse's Struts 2 support could use a bit of love to be aligned with Struts 2's recommended practices, but I didn't want to spend the time doing it as part of this exercise.

With Struts 2, I tried the path-mapping like I did with Spring MVC, but ran into issues. Instead, I opted to use an ".action" extension by changing struts.action.extension from "html" to "action," in struts.xml. Then I had to do a bunch of filter re-ordering and dispatcher changes. Before, with a .html extension, I had all filters mapped to /* and in the following order.

Filter Name	Dispatchers
securityFilter	request
rewriteFilter	request, forward
struts-prepare	request
sitemesh	request, forward, include
staticFilter	request, forward
struts	request

Similar to Spring MVC, I had to remove the rewriteFilter in front of the securityFilter and I was able to remove the staticFilter. I also had to map the struts filter to *.action instead of /* to stop Struts from trying to catch static asset and DWR/CXF requests. Below is the order of filters and their dispatchers that seems to work best.

Filter Name	Dispatchers
rewriteFilter	request
securityFilter	request, forward, include
struts-prepare	request, forward
sitemesh	request, forward, include
struts	forward

From there, it was a matter of modifying urlrewrite.xml to have the following catch-all and rules for static assets, j_security_check and DWR/CXF.

<rule match-type="regex">
    <from>^([^?]*)/([^?/\.]+)(\?.*)?$</from>
    <to last="true">$1/$2.action$3</to>
</rule>
<outbound-rule match-type="regex">
    <from>^(.*)\.action(\?.*)?$</from>
    <to last="false">$1$2</to>
</outbound-rule>

JSF
JSF was by far the most difficult to get extensionless URLs working with. I'm not convinced it's impossible, but I spent a several hours over a few days and was unsuccessful in completely removing them. I was able to make things work so I could request pages without an extension, but found when clicking buttons and links, the extension would often show up in the URL. I'm also still using JSF 1.2, so it's possible that upgrading to 2.0 would solve many of the issues I encountered.

For the time being, I've changed my FacesServlet mapping from *.html to *.jsf. As with Struts, I had issues when I tried to map it to /app/*. Other changes include changing the order of dispatchers and filters, the good ol' catch-all in urlrewrite.xml and modifying security.xml. For some reason, I wasn't able to get file upload working without adding an exception to the outbound-rule.

<rule match-type="regex">
    <from>^([^?]*)/([^?/\.]+)(\?.*)?$</from>
    <to last="true">$1/$2.jsf</to>
</rule>
<outbound-rule match-type="regex">
  <!-- TODO: Figure out how to make file upload work w/o using *.jsf -->
    <condition type="path-info">selectFile</condition>
    <from>^(.*)\.jsf(\?.*)?$</from>
    <to last="false">$1$2</to>
</outbound-rule>

I also spent a couple hours trying to get Pretty Faces to work. I wrote about my issues on the forums. I tried writing a custom Processor to strip the extension, but found that I'd get into an infinite loop where the processor kept getting called. To workaround this, I tried using Spring's RequestContextHolder to ensure the processor only got invoked once, but that proved fruitless. Finally, I tried inbound and outbound custom processors, but failed to get those working. The final thing I tried was url-mappings for each page in pretty-config.xml.

<url-mapping>
  <pattern value="/admin/users"/>
  <view-id value="/admin/users.jsf"/>
</url-mapping>
<url-mapping>
  <pattern value="/mainMenu"/>
  <view-id value="/mainMenu.jsf"/>
</url-mapping>

The issue with doing this was that some of the navigation rules in my faces-config.xml stopped working. I didn't spend much time trying to diagnose the problem because I didn't like having to add an entry for each page in the application. The one nice thing about Pretty Faces is it did allow me to do things like the following, which I formerly did with a form that auto-submitted when the page loaded.

<url-mapping>
  <pattern value="/passwordHint/#{username}"/>
  <view-id value="/passwordHint.jsf"/>
  <action>#{passwordHint.execute}</action>
</url-mapping>

Conclusion
My journey implementing extensionless URLs was an interesting one, and I solidified my knowledge about ordering of filters, dispatchers and the UrlRewriteFilter. I still think I have more to learn about properly implementing extensionless URLs in Struts 2 and JSF and I hope to do that in the near future. I believe Struts' Convention Plugin will help me and JSF 2 + Pretty Faces will hopefully work nicely too. Of course, it'd be great if all Java Web Frameworks had an easy mechanism for producing and consuming extensionless URLs. In the meantime, thank goodness for the UrlRewriteFilter.

If you'd like to try AppFuse and its shiny new URLs, see the QuickStart Guide and choose the 2.1.0-SNAPSHOT version.

How I Calculated Ratings for My JVM Web Frameworks Comparison

2010-12-06T11:55:18-07:00

When I re-wrote my Comparing JVM Web Frameworks presentation from scratch, I decided to add a matrix that allows you to rate a framework based on 20 different criteria. The reason I did this was because I'd used this method when choosing an Ajax framework for Evite last year. The matrix seemed to work well for selecting the top 5 frameworks, but it also inspired a lot of discussion in the community that my ratings were wrong.

I expected this, as I certainly don't know every framework as well as I'd like. The mistake I made was asking for the community to provide feedback on my ratings without describing how I arrived at them. From Peter Thomas's blog:

What you are doing is adjusting ratings based on who in the community shouts the loudest. I can't help saying that this approach comes across as highly arrogant and condescending, you seem to expect framework developers and proponents to rush over and fawn over you to get better ratings, like waiters in a restaurant trying to impress a food-critic for Michelin stars.

I apologize for giving this impression. It certainly wasn't my intent. By having simple numbers (1.0 == framework does well, 0.5 == framework is OK and 0 == framework not good at criteria) with no rationalization, I can see how the matrix can be interpreted as useless (or to put it bluntly, as something you should wipe your ass with). I don't blame folks for getting angry.

For my Rich Web Experience presentation, I documented why I gave each framework the rating I did. Hopefully this will allow folks to critique my ratings more constructively and I can make the numbers more accurate. You can view this document below or on Google Docs.

In the end, what I was hoping to do with this matrix was to simply highlight a technique for choosing a web framework. Furthermore, I think adding a "weight" to each criteria is important because things like books often aren't as important as REST support. To show how this might be done, I added a second sheet to the matrix and made up some weighting numbers. I'd expect anyone that wants to use this to downloaded the matrix, verify the ratings are accurate for your beliefs and weight the criteria accordingly.

Of course, as I and many others have said, the best way to choose a web framework is to try them yourself. I emphasized this at the end of my presentation with the following two slides.

My Comparing JVM Web Frameworks Presentation from Devoxx 2010

2010-11-18T05:23:10-07:00

This week, I've been having a great time in Antwerp, Belgium at the Devoxx Conference. This morning, I had the pleasure of delivering my Comparing JVM Web Frameworks talk. I thoroughly enjoyed giving this presentation, especially to such a large audience. You can view the presentation below (if you have Flash installed) or download it here.

Unlike previous years, I chose to come up with a spreadsheet matrix that shows why I chose the 5 I did. This spreadsheet and rankings given to each framework are likely to be debated, as I don't know all the frameworks as well as I'd like to. Also, the missing column on this spreadsheet is a "weighting" column where you can prioritize certain criteria like I've done in the past when Comparing Ajax Frameworks. If you believe there are incorrect numbers, please let me know and I'll try to get those fixed before I do this talk again at The Rich Web Experience.

One thing that doesn't come across in this presentation is that I believe anyone can use this matrix, and weightings, to make any of these frameworks come out on top. I also believe web frameworks are like spaghetti sauce in The Ketchup Conundrum. That is, the only way to make more happy spaghetti sauce lovers was to make more types of spaghetti sauce. You can read more about this in my There is no "best" web framework article.

Update: If you disagree with the various ratings I gave to web frameworks in this presentation, please provide your opinions by filling out this survey. Thanks to Sebastien Arbogast for setting this up.

Update: Sebastien has posted his survey results at JVM Web Framework Survey, First Results.

Update 12/6: A video of this presentation is now available on Parleys.com.

P.S. My current gig is ending in mid-December. If you're looking for a UI Architect with a passion for open source frameworks, please let me know.

AppFuse 2.1 Milestone 2 Released

2010-11-15T15:28:57-07:00

I'm pleased to announce the 2nd milestone release of AppFuse 2.1. This release includes upgrades to all dependencies to bring them up-to-date with their latest releases. Most notable are Spring 3 and Struts 2.1. This release fixes many issues with archetypes and contains many improvements to support Maven 3. For more details on specific changes see the 2.1.0 M2 release notes.

What is AppFuse?
AppFuse is an open source project and application that uses open source frameworks to help you develop Web applications quickly and efficiently. It was originally developed to eliminate the ramp-up time when building new web applications. At its core, AppFuse is a project skeleton, similar to the one that's created by your IDE when you click through a wizard to create a new web project. If you use JRebel with AppFuse, you can achieve zero-turnaround in your project and develop features without restarting the server.

Release Details
Archetypes now include all the source for the web modules so using jetty:run and your IDE will work much smoother now. The backend is still embedded in JARs, enabling you to choose with persistence framework (Hibernate, iBATIS or JPA) you'd like to use. If you want to modify the source for that, add the core classes to your project or run "appfuse:full-source".

AppFuse comes in a number of different flavors. It offers "light", "basic" and "modular" and archetypes. Light archetypes use an embedded H2 database and contain a simple CRUD example. In the final 2.1.0 release, the light archetypes will allow code generation like the basic and modular archetypes. Basic archetypes have web services using CXF, authentication from Spring Security and features including signup, login, file upload and CSS theming. Modular archetypes are similar to basic archetypes, except they have multiple modules which allows you to separate your services from your web project.

AppFuse provides archetypes for JSF, Spring MVC, Struts 2 and Tapestry 5. The light archetypes are available for these frameworks, as well as for Spring MVC + FreeMarker, Stripes and Wicket.

Please note that this release does not contain updates to the documentation. Code generation will work, but it's likely that some content in the tutorials won't match. For example, you can use annotations (vs. XML) for Spring MVC and Tapestry is a whole new framework. I'll be working on documentation over the next several weeks in preparation for the 2.1 final release.

For information on creating a new project, please see the QuickStart Guide.

If you have questions about AppFuse, please read the FAQ or join the user mailing list. If you find bugs, please create an issue in JIRA.

Thanks to everyone for their help contributing patches, writing documentation and participating on the mailing lists.

AppFuse 2.1 Milestone 1 Released

2009-11-19T07:16:36-07:00

The AppFuse Team is pleased to announce the first milestone release of AppFuse 2.1. This release includes upgrades to all dependencies to bring them up-to-date with their latest releases. Most notable are Hibernate, Spring and Tapestry 5.

What is AppFuse?
AppFuse is an open source project and application that uses open source tools built on the Java platform to help you develop Web applications quickly and efficiently. It was originally developed to eliminate the ramp-up time found when building new web applications for customers. At its core, AppFuse is a project skeleton, similar to the one that's created by your IDE when you click through a wizard to create a new web project.

Release Details
Archetypes now include all the source for the web modules so using jetty:run and your IDE will work much smoother now. The backend is still embedded in JARs, enabling you to choose which persistence framework (Hibernate, iBATIS or JPA) you'd like to use. If you want to modify the source for that, add the core classes to your project or run appfuse:full-source.

In addition, AppFuse Light has been converted to Maven and has archetypes available. AppFuse provides archetypes for JSF, Spring MVC, Struts 2 and Tapestry 5. The light archetypes are available for these frameworks, as well as for Spring MVC + FreeMarker, Stripes and Wicket.

Other notable improvements:

Added Compass support thanks to a patch from Shay Banon.
Upgraded from XFire to CXF for Web Services.
Moved Maven repository to Sonatype's OSS Repository Hosting for snapshots and releasing to Maven Central. There are no longer any AppFuse-specific artifacts, all are available in central. Thanks to Sonatype for this great service and its excellent repository manager.
Upgraded to Canoo WebTest 3.0. Now if we could just get its Maven Plugin moved to Codehaus.
Added Ajaxified Body to AppFuse Light archetypes.
Infrastructure upgrades, including JIRA 4, Confluence 3, FishEye 2, Bamboo 2 and Crowd 1.6. Many thanks to Atlassian and Contegix for their excellent products and services.
For more details on specific changes see the release notes.

Please note that this release does not contain updates to the documentation. Code generation will work, but it's likely that some content in the tutorials won't match. For example, you can use annotations (vs. XML) for dependency injection and Tapestry is a whole new framework. I'll be working on documentation over the next several weeks in preparation for Milestone 2.

AppFuse is available as several Maven archetypes. For information on creating a new project, please see the QuickStart Guide.

To learn more about AppFuse, please read Ryan Withers' Igniting your applications with AppFuse.

The 2.x series of AppFuse has a minimum requirement of the following specification versions:

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

If you have questions about AppFuse, please read the FAQ or join the user mailing list. If you find bugs, please create an issue in JIRA.

Thanks to everyone for their help contributing code, writing documentation, posting to the mailing lists, and logging issues.

AppFuse Light converted to Maven modules, upgraded to Tapestry 5 and Stripes 1.5

2008-12-20T18:42:03-07:00

This past week, I stayed up a couple of late nights to do some of the AppFuse Light work I wrote about in October. I converted all web frameworks to Maven modules, as well as made them inherit from the appfuse-web project. Below is what the new module structure looks like:

At this point, the project is ready to import into AppFuse's SVN project. Here's a list of other changes I made:

Modules now depend on AppFuse's backend and allow you to use Hibernate, JPA or iBATIS as the persistence framework. Implementations for Spring JDBC, OJB and JDO have been removed.
Upgraded to JWebUnit 2.1, which now uses HtmlUnit under the hood and has much better JavaScript support. It also has Selenium support, but I've yet to try it.
Ajaxified Body integrated into all frameworks. You can easily turn it off by modifying the global.js file.
Prototype and Scriptaculous loaded from Google's Ajax Libraries CDN.
Upgraded to Tapestry 5. Mad props to Serge Eby and his tapestry5-appfuse project for showing me how to do this. Serge became a committer on AppFuse recently, so hopefully we'll continue to see great things from the Tapestry 5 support. I really like the clean URLs and minimum configuration required in Tapestry 5. It's testing framework is nice too, but I believe it could be improved.
Upgraded to Stripes 1.5. This was easy and painless. I'm definitely a fan of Stripes and look forward to reading the Stripes book on my bookshelf.
Dropped support for: Struts 1.x, WebWork, Spring MVC + Velocity.

If you want to try any of these applications, you can create archetypes using the following commands:

svn co https://appfuse-light.dev.java.net/svn/appfuse-light/trunk appfuse-light
cd appfuse-light/preferred-web-framework
mvn archetype:create-from-project
cd target/generated-sources/archetype
mvn install
cd ~/dev
mvn archetype:generate # The new archetype should show up as an option

Next steps include figuring out a way to flatten the inherited dependencies and plugins so archetype:create-from-project can create truly standalone projects. Please let me know if you have any questions.

RESTful Web Applications with Subbu Allamaraju

2008-10-24T09:52:02-06:00

Subbu works at Yahoo! developing standards, patterns and practices for HTTP web languages. In the past, he was a web service and Java developer. He was also a standards contributor at BEA and an author of books on Java EE. His current passion is HTTP and REST. Subbu confesses that he's not a web developer, has no interest in the internals of programming models used for web frameworks and he's only interested in the visible aspects of the architecture.

"The Web is Mostly Restful"

Being RESTful in an abstract sense means:

Resources are named by URIs
Resources have representations (Atom, HTML, JSON, XML)
Resources contain contextual links to allow navigation of state
There's a Uniform Interface

In the web today, some resources and URIs are personalized, but most are not. Some depend on sessions, but most do not. The consequence of a personalized UI with a non-unique URI is you cannot rely on browser caching.

The web is full of different representations (HTML, XML, JS, PDF, CSS, Flash). The problem with HTML is you can't tell links that you want a particular representation based of a link. The links are hard-coded to be a particular content-type. However, some media types on responses are ignored. This is often a problem with browsers and whether the user has plugins installed.

The Uniform Interface for the web is HTML and primarily links and forms (GET and POST). There's still some misconceptions (e.g. POST is secure). However, it's not about security, it's about idempotency and safety. You need to make sure you only use POST when you're changing data. POSTs are not repeatable. GET URIs are not always refreshable, which is quite unfortunate. Users shouldn't have to fight the back button.

Caching is a fundamental aspect of the web. Even in a personalized site, most of the content can be cached. The web is read-only for the most part. However, many enterprise web applications don't take advantage of caching. This is fine when there's not that many users, but it's bad when you want to scale to thousands of users. There's several frameworks that use cache-busting and prefer backend caching over HTTP caching. These frameworks are not using the web like they should.

Backend caching (e.g. Memcached) uses a non-uniform interface and you need to explicitly program to it. Frontend/HTTP caching has a uniform interface that's pluggable. Backend caching is generally more expensive to develop and deploy. There are cases where data should be cached on the backend, but you shouldn't focus all on backend caching w/o doing some frontend caching.

With Ajax, you get more opportunities to be RESTful. XMLHttpRequest is another HTTP client that can be programmed to. It has full support for the uniform interface, which allows content negotiation, optimistic concurrency and caching. Cross-domain hacks can be done with <script> and <iframe> to tunnel requests over GET. The W3C has been working for the last two years on how to do cross-domain Ajax w/o using hacks. The problem with current cross-domain implementations is they often use GET for everything, which isn't very RESTful. Subbu recommends using a proxy on the same domain if you do need to talk to other domains. This will allow your Ajax code to remain RESTful.

Web Frameworks
Web development is hard because of all the moving pieces that exist. Because of this, many web frameworks have been created to solve the various problems. In 1997, there were servlets. They provided basic plumbing and closely reflected HTTP/1.1. Servlets provided a poor programming model, but it allowed a lot of frameworks to be built on top of it. We don't use servlets to write applications, only to write application frameworks. The second era came about in 2001 when Action-oriented frameworks became popular. In 2004, JSF and friends came to play. JSF is a component-based framework with known limitations (complex, slow, uses POST for almost everything, Ajax is difficult). These limitations have resulted in a number of third-party patches being developed to solve these issues.

JSF was designed to use the request to create a component tree that maintains state. Unfortunately, the state is not something the developer has control over. It's not the state of the application, it's the state of the components. The client's knowledge of the state is mentioned with a cookie and the server keeps the state in the session. The problem with JSF is you don't have a choice of state in your application - you can't write stateless applications like you can with servlets.

JSF uses overloaded URIs for its resources. When you have one URI with multiple representations, there's no way to tell how a representation was chosen. JSF's compromise is to allow client-side state saving. However, they do this by putting hidden field in the form and requiring POST for navigation.

JSF vs. REST
Basically, these two are at opposite extremes. JSF is focused heavily on a UI component model. The people that developed it misinterpreted how the web works and made some fundamental questionable choices. You can patch it, but you can not fix it.

Web 2.0 Frameworks
GWT is a cross-compilation based framework. You write Java to generate JavaScript (b/c everyone hates writing JavaScript). It mashes client and server code into a single source. These layers communicate using GWT-RPC. Typical RPC concerns do not apply since code generation handles coupling and the client is downloaded from the same application. GWT-PRC does POSTs to the server and uses HTTP like a transport layer. To be fair, GWT does allow you to use a RequestBuilder to use the web like it should be used. This class allows more control over HTTP requests, it supports GET and POST and it allows so-called RESTful layers (GWT-REST and GET-Restlet). GWT is focused heavily on ease-of-use, which is good. It's modeled after RPC and breaks the uniform interface and focuses on backend caching. Unlike JSF, GWT is fixable, but the community tends to use RPC instead of RequestBuilder.

SOFEA has a central promise of SOA. Business logic is a reusable service that changes less often. The presentation application calls those services and changes more often. The nice thing about this type of architecture is it allows a separation of concerns and loose coupling. However, it doesn't embrace REST like it should. Appcelerator is an implementation of SOFEA that has a Ruby on Rails-like usability. However, it uses a SOAP/HTTP style with messaging and POSTs to a single URI. Appcelerator is interesting, but it introduces a different style of coupling. It breaks URI opacity and client deals with POX instead of links.

Conclusion
Don't fight the architecture of the web. Innovate and enhance instead of breaking. If nothing else, break judiciously. As developers, we should demand more from our frameworks and make sure they use the web and HTTP like it should be used.

What's wrong with JSF

2008-08-25T18:53:31-06:00

The developers of Seam have come up with a list of major issues with JSF. I'm assuming many of these issues are fixed by Seam, but it's interesting to note how they've somewhat admitted that JSF has many flaws. Note that there's a lot of references to Struts and WebWork.

Hopefully many of these will be fixed in JSF 2. If REST support is an important feature for web frameworks, it'll be be interesting to see how the component frameworks handle it. It'd be great if they provided native support. Oh wait, then they'd be action-based frameworks.

RE: Which is the Hottest Java Web Framework?

2008-06-10T22:39:08-06:00

The "Break it Down" Blog has a lengthy post on Which is the Hottest Java Web Framework? Or Maybe Not Java? Comparing Java Web Frameworks is hard because so many people are passionate about the framework they know best. Add a couple more like Flex and Ruby on Rails and its downright difficult. Nevertheless, this post is good in that it contains a lot of pretty trend graphs and it looks like the author has done some good research. It's likely the folks that will scream foul are the ones that did poor in the comparison (Tapestry and Stripes, I'm talking about you).

Surprising among the top Java Web Frameworks is the rise of Struts 2:

To quote:

Which is much more interesting I think is how Wicket adoption has stayed almost flat while Struts 2 adoption has spiked. Spring MVC/WebFlow seems to be going no where fast and racing JBoss Seam there.

The popularity of Struts 2 really caught me off guard with it being quite a bit different from Struts 1, I figured it got thrown into the "just another web framework" category, but I guess there is something in a name and it's doing quite well.

Regardless of what you think of the post and trends, you have to appreciate the amount of time the author put into it.

AppFuse 2.0.2 Released

2008-05-11T23:25:40-06:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0.2. This release includes upgrades to Spring Security 2.0, jMock 2.4, the ability to customize code generation templates and many bug fixes.

For information on upgrading from 2.0.1, see the Release Notes or changelog. AppFuse 2.0.2 is available as a Maven archetype. For information on creating a new project using AppFuse, please see the QuickStart Guide or the demos and videos.

To learn more about AppFuse, please read Ryan Withers' Igniting your applications with AppFuse.

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

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ. Join the user mailing list if you have any questions.

Thanks to everyone for their help contributing code, writing documentation, posting to the mailing lists, and logging issues.

Please post any issues you have with this release to the mailing list.

David Sachdev on Web Framework Proliferation

2008-02-22T14:47:44-07:00

David Sachdev left the following comment in my post about the Java Web Framework Smackdown at TSSJS in Vegas:

The number of web frameworks out there is just astonishing, and in alot of ways I think that there is need for some consolidation in some way, shape or form. If you work in the Java world there is a sense of consolidation in the ORM space these days with JPA (the Java Persistence API). Sure if you are working strictly with JPA it is a bit more limiting then working directly with Hibernate, iBatis, or TopLink - but you no longer worry that you have made a critical misstep in your architecture by tying yourself do a particular ORM implementation. Similarly Spring gives you that similar "loosely coupled" feel that if Google's Guice because appealing to you, you don't feel like you've wasted all your framework foo on Spring. But web frameworks....that's another story.

I think if you had asked me a few months ago, I would have told you that the industry is promoting JSF (Java Server Faces). Everything from support in the IDEs to the availability of AJAX frameworks...and of course a flexible life cycle that allows for alternate implementations and various code to plug or be weaved in to the life cycle. And that while JSF on its own left quite a bit to be desired, the JBoss Seam project really has filled in the gaps in JSF, and in fact brought Java web development closer in agility to the Rails and Grails of the world that tout quickly built and deployed web applications.

But the thing that you continue to hear is that programming in JSF is painful. And you hear that EVERYONE used to use Struts. And that it is time to move past Struts. And given that, you have to consider Webwork and the merger of Struts2 into that framework - and their claims of rapid development. But you also have to consider Spring WebFlow and how that may help solve your JSF ills given that everyone is building off of the Spring Framework and they have been so good about keeping the framework updated and integrating the best of what is out there while innovating themselves. And then if you are looking at Spring WebFlow, you kinda have to go "Wait, but what about Spring MVC?"

Given its age, you might quickly dismiss Spring MVC until you realize that Grails is build upon it. Grails, that web platform that every java developer is either working with, or intends to work with soon. (Come on, you all have made the Ruby/Rails, Groovy/Grails, JRuby decision in favor of G2, right? I mean all the flexibility of what is out there in the Java world on top of the JVM, with a language that doesn't suck the life outta you....) And then you have to wonder that if you build upon Spring MVC as well as using Groovy and Grails where appropriate, might you be able to make that killer app in half the time.

But wait, you didn't think your choices were nearly that simple did you? There is this wonderful software company out in Mountain View that we need to pay attention too. In Google We Trust, right? And even if you don't worship at the Temple of the G (TOTG) like Sprout, you don't want to ignore them. And, if you've looked at the Google Web Toolkit (GWT) and weren't at least slightly impressed, I would be surprised. And if you are looking at the GWT, you can't totally ignore Yahoo's YUI - maybe with some of the what Prototype, Scriptaculous, or DoJo offer you. And then someone will come over and point out Echo2 to you, and well you have to admit, their demo looks nice. And well, there is Adobe Flex, and OpenLaszlo - I mean after all isn't Web 2.0 all about Rich Internet Applications. And surely you've heard that the performance of Swing is so much better these days and the "power of the modern Java applet"

So at the end of it all, you've got yourself alot of R&D to do, and just as you thing you've got a good grasp for the offerings out there, new and improved versions are out. And don't worry, someone else is also busy working on a new and greater web framework that you have to consider.

Wow - that's quite a mouthful David. Well written!

P.S. The Early Bird Deadline for TSSJS is today.

Java Web Framework Smackdown at TSSJS in Vegas

2008-01-11T12:06:24-07:00

This year's TSSJS is starting to look like an excellent conference. I'm particularly excited to be moderating the following Expert Panel.

Java Web Framework Smackdown: Struts 2, Spring MVC, Grails, Seam/JSF and Wicket
The leading advocates of today's popular Web frameworks will duel under the Vegas Lights. Come and learn when to use your favorite framework and to see if it can live up to its hype.

We're talking about productivity, scalability and maintainability of Java-based Web applications. The emerging trend is that simplicity is better and productivity matters. Furthermore, if maintainability is the most costly part of any application -- how do these frameworks perform?

Attend if you're a Java Web developer, or if you simply like good entertainment. A working knowledge of the popular Java Web framework options will make this session more fun. If you haven't worked with any framework, come and learn who has the best spokesman.

I plan on bringing the boxing bell from OSCON 2005 to make this session one of the best in the show. I'll be coming up with a list of questions for these experts in the next couple of months. In the meantime, if you have any suggestions, please let me know.

With a venue like The Venetian, why wouldn't you go?

AppFuse 2.0.1 Released

2007-11-26T09:29:43-07:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0.1. This release squashes a number of bugs and includes an upgrade to Spring 2.5. To learn more about Spring 2.5's features, see InfoQ's What's New in Spring 2.5: Part 1 article.

For information on upgrading from 2.0, see the 2.0.1 Release Notes or changelog. AppFuse 2.0.1 is available as a Maven archetype. For information on creating a new project using AppFuse, please see the QuickStart Guide or the demos and videos.

What is AppFuse? Click here to find out.

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

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ. Join the user mailing list if you have any questions.

Thanks to everyone for their help contributing code, writing documentation, posting to the mailing lists, and logging issues.

We greatly appreciate the help from our sponsors, particularly Atlassian, Contegix, JetBrains, and Java.net. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project. Thanks guys - you rock!

Please post any issues you have with this release to the mailing list.

Xebia Web Framework Contest

2007-10-30T09:32:34-06:00

I found an interesting blog post today about a contest (English translation) a French company (Xebia) had with some Java web frameworks.

4 teams have developed the same web application, each with a framework (very) different. The frameworks used were:

Struts 2
Google Web ToolKit
Wicket
My Faces (JSF)

Overall, I think it's a good summary of the strengths and weaknesses of the various frameworks.

AppFuse 2.0 Released!

2007-09-18T15:22:20-06:00

I'm extremely happy to announce we've finally finished developing AppFuse 2.0. The road to AppFuse 2.0 has been a long journey through Mavenland, annotations and generics. Thanks to all the developers, contributors and users for helping test, polish and prove that AppFuse 2 is an excellent solution for developing Java-based applications. Your time, patience and usage of AppFuse has made it the strong foundation it is today. Last but certainly not least, thanks to all the great Java developers who wrote the frameworks that AppFuse uses - we're truly standing on the shoulders of giants.

What is AppFuse? Click here to find out.

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

If you've used AppFuse 1.x, but not 2.x, you'll might want to read our Frequently Asked Questions. If you have any questions or issues, please post them to the user mailing list. The Maven Reference Guide has a map of Ant » Maven commands. Maven for Newbies might also be useful if you've never used Maven before. There is some support for Ant in this release.

AppFuse 2.0 contains over 200 pages of documentation, downloadable as a PDF (3 MB). You can also download all its dependencies and install them in your local repository if you want to work offline.

For more information, please see the 2.0 Release Notes. The 2.0 series of AppFuse has a minimum requirement of the following specification versions:

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

New features in AppFuse 2.0 include:

Maven 2 Integration
Upgraded WebWork to Struts 2
JDK 5, Annotations, JSP 2.0, Servlet 2.4
JPA Support
Generic CRUD backend
Full Eclipse, IDEA and NetBeans support
Fast startup and no deploy with Maven Jetty Plugin
Testable on multiple appservers and databases with Cargo and profiles

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues.

We're also grateful for the help from our sponsors, particularly Atlassian, Contegix, JetBrains, and Java.net. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project. Thanks guys - you rock!

Comments and issues should be posted to the mailing list.

Does Struts 2 suck?

2007-09-05T11:21:57-06:00

As far as I can tell, Struts 2 sucks. To be fair, so does Stripes. Why? Because there's no developer feedback for invalid properties or OGNL Expressions. What does this mean? It means if you fat-finger a property name, nothing happens. The OGNL exception is swallowed and you never know you did anything wrong. Furthermore, no one seems to care. The XWork folks will help you build, but not solve the problem. This seems like a major deal-breaker to me, However, I also believe it can be fixed - so maybe there's hope.

To demonstrate the problem, I did an experiment. I used the "user details" page in AppFuse Light to fat-finger a property name for the following frameworks: Struts 1, WebWork, Struts 2, JSF, Spring MVC, Stripes, Tapestry and Wicket. First, I tried changing the "lastName" property to "LastName" to see if the framework's property evaluation was case-sensitive. I found that with WebWork/Struts 2, Stripes and Tapestry, the property is not case-sensitive. I prefer case-sensitivity, but maybe that's because I prefer Unix over Windows.

The 2nd thing I tried was changing "lastName" to "pastName" to see if I'd get an error. An error occurred for all the frameworks mentioned, except for WebWork/Struts 2 and Stripes. This makes me believe these frameworks suck. The both use OGNL, so they could blame it on that, but Tapestry uses OGNL and it presents an error message. After this small experiment, my conclusion is the following frameworks have the best developer feedback:

Struts 1
JSF
Spring MVC
Tapestry
Wicket*

* Wicket seems like it needs some work as all it presents is "Internal Error" and makes you dig through your log files to find the problem.

Without good developer feedback, how can you have good productivity?

Dear Struts 2 and Stripes Developers,

What do you think about improving your error messages for invalid properties and expressions? Is this a feature you think you could add? We'd love it if you did.

Sincerely,

Your Users

Click here for some screenshots of how a fat-fingered property looks in various frameworks:

Update: Stripes doesn't suck and Wicket has excellent error reporting. See my comment below for more details.

Update 2: I've created a patch to (hopefully) solve this issue in XWork. If you have any feedback on ways to improve this patch, I'd love to hear about it.

AppFuse 2.0 RC1 Released

2007-09-04T01:42:15-06:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0 RC1! This release marks a huge step in the march to releasing AppFuse 2.0. This release puts the finishing touches on the AppFuse Maven Plugin (AMP), which offers CRUD generation, as well as the ability to change AppFuse from "embedded mode" to "full source" (like 1.x). In addition, we've addressed over 100 issues in preparation for the final 2.0 release. We hope to fix any bugs related to this release and release 2.0 Final in the next week or two.

The videos still represent how M5 works, but things have been simplified (now you don't need to run appfuse:install after appfuse:gen).

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

If you've used AppFuse 1.x, but not 2.x, you'll want to read the FAQ. Join the user mailing list if you have any questions. The Maven Reference Guide has a map of Ant » Maven commands. Maven for Newbies might also be useful if you've never used Maven before. There is some support for Ant in this release.

For more information, please see the 2.0 RC1 Release Notes. The 2.0 series of AppFuse has a minimum requirement of the following specification versions:

Java Servlet 2.4 and JSP 2.0 (2.1 for JSF)
Java 5+

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, Contegix, JetBrains, and Java.net. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project. Thanks guys - you rock!

Comments and issues should be posted to the mailing list.

Update: I've uploaded a 247-page PDF version of the RC1 documentation to java.net. This PDF contains the relevant pages from the wiki that help you develop with AppFuse 2.0. Who knew I'd end up writing another book?

Spring Web Flow 2.0

2007-08-29T15:49:15-06:00

The first milestone release of Spring Web Flow 2.0 has been released.

We are pleased to announce that the first milestone of the next generation version of Spring Web Flow is now available. Spring Web Flow 2.0 M1 introduces several major new features, including support for flow-managed persistence contexts, improved support for Java Server Faces, full unified expression language (EL) support, and a more comprehensive sample web application.

I think the most interesting part of this release is Spring Faces:

Spring Web Flow 2.0 M1 introduces the Spring Faces module (spring-faces-2.0-m1.jar), a component shipped with the Web Flow distribution that contains first-class support for organizations developing web applications with Java Server Faces. The pre-existing Web Flow + JSF integration has been factored out to this project, and this project will be the home of all future JSF integration work.

The Spring Faces module provides the Spring community a dedicated project for exploring additional JSF integration opportunities. The initial work in 2.0 M1 on this front introduces integration with Ext, a popular Javascript GUI widget framework.

Of course, I also like how the new sample app looks a lot like one of Seam's demos.

JSF has needed a good client-side validation framework for quite some time. I also like the Ext integration as most JSF date pickers are hideous. Well done gents.

Integrating Struts 2 + JSF + Facelets

2007-07-26T12:13:59-06:00

What if you didn't have to choose between a request-based framework and a component-based framework? What if you could use them together and use request-based for some pages and component-based for others? This is the functionality that the Struts 2 JSF Plugin provides.

To be fair, the JSF-Spring project says it does the same thing for Spring MVC + JSF, but there doesn't appear to be any documentation.

I did some prototyping of Struts 2 + JSF and discovered that it does indeed work. I also discovered that there's no documentation on integrating it with Facelets. Luckily, it's pretty easy to do - hence my reason for writing this entry. You might ask why I want to use Facelets when JSF 1.2 supports JSP fairly well? My reason is because JSP 2.1 hijacks #{}, which Struts 2's OGNL uses for some expressions. Because of this, I want to be able to run on a JSP 2.0 container until a workaround comes along. Sun's JSF 1.2 RI can run on a JSP 2.0 container, while MyFaces 2.1 cannot (at least in my experience).

There's two ways to get Struts 2 + JSF + Facelets working:

Create a WEB-INF/faces-config.xml file and override the default view-handler:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
        http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
    version="1.2">

    <application>
        <view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
    </application>
</faces-config>

The 2nd way is to use Ajax4JSF and declare the view-handler in your web.xml (allowing you to get rid of faces-config.xml):

<context-param>
    <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
    <param-value>com.sun.facelets.FaceletViewHandler</param-value>
</context-param>

NOTE: You have to use 2nd method if you want to use Ajax4JSF. It won't read the view-handler from faces-config.xml.

If you're using SiteMesh, you may have to add another <parser> element to your sitemesh.xml to get Facelets pages decorated:

<parser content-type="application/xhtml+xml"
    class="com.opensymphony.module.sitemesh.parser.HTMLPageParser"/>

Thanks to Laurie Harper for his assistance figuring this stuff out.

Now you might ask - why would you want to do this? For one, Struts 2 has a better navigation model (IMO) than JSF. Also, if developers want to use JSF and think it's a better way for a certain module - let them go to it!

OSCON 2007: Comparing Java Web Frameworks

2007-07-25T16:50:55-06:00

This afternoon I delivered my Comparing Java Web Frameworks talk at OSCON in Portland. I told attendees I'd post it here afterwards, so here it is:Download Comparing Java Web Frameworks Presentation (5.1 MB)

For comments on this presentation from earlier this year, see related postings from ApacheCon EU and JA-SIG. This presentation is pretty much the same as the one from ApacheCon and JA-SIG, except it has a different theme and I chopped out the Sweetspots section (due to time constraints).

Portland is great this time of year, but unfortunately I won't be sticking around. I'm heading down to Salem to work remotely for a couple of days, returning for the Oregon Brewers Festival on Friday and heading back to Denver on Saturday. I'll be glad when July is over - I've traveled to a new state every week.

Thoughts on MyFaces 1.2 vs. JSF RI

2007-07-19T11:32:18-06:00

Yesterday, MyFaces 1.2 was released. I took the opportunity to upgrade AppFuse Light and found it surprisingly easy to do so. The only issue I ran into is my testing logic no longer works. I haven't had a chance to dive deeper into trying to fix the problem, but I did check the code in.

Since I'm using Facelets with MyFaces, I figured it should be possible to run my app on Tomcat 5.x. No dice. I tried replacing MyFaces with Sun's RI (version 1.2_04) and voila! - it works.

From what I learned yesterday, it appears that MyFaces 1.2 will only run on a container that supports JSP 2.1. Sun's RI, on the other hand, will run on a Servlet 2.4/JSP 2.0 container. I don't know if Sun's RI is doing things properly, but it doesn't seem like Servlet 2.5 is required (which is kinda nice IMO).

You might ask why I care about JSP 2.0 vs. JSP 2.1? In reality, I don't. However, if I were to mix and match Struts 2 and JSF in the same application (using the Struts 2 JSF Plugin), I'd like to do it on a JSP 2.0 container. Why? Because OGNL (the EL in Struts 2) uses the pound sign (#) for expressions and JSP 2.1 hijacked that. Until the Struts team fixes that, I'm stuck on JSP 2.0. The workaround (disabling EL for all JSPs) doesn't seem like a good option to me.

How popular is your web framework?

2007-07-13T11:43:29-06:00

From the Struts user mailing list:

Since its release in June 2001, Apache Struts has become the most popular web framework for Java. Six years later, by any objective measure, Struts is still Java's most popular web framework.

In February and March 2007, the group released both Struts 1.3.8 and Struts 2.0.6 to the general public, and Struts downloads zoomed to over 340,000 a month from the Apache site alone. And this is just the tip of the iceberg. Most copies of Struts are downloaded from an network of mirrors or obtained from Maven repositories.

So how popular is Struts compared to the other heavy hitters like Spring and Hibernate? Spring has about 1/2 as many (80K) downloads in the same period and so does Hibernate. How do MyFaces, Wicket and Tapestry stack up? Here's their best download numbers in the past few months:

MyFaces: ~12K (and that's only because of a rate 3-times-normal spike)
Tapestry: ~12K
Wicket: ~10K

Sorry JSF, you appear to be losing. Badly. This is an incorrect statement as pointed out by commentors. Thanks for keeping me honest guys.

Disclaimer: Yes, I realize that these statistics are not very accurate, especially considering Maven. Unfortunately, until Maven has repository download stats, this information is the best we've got.

AppFuse 2.0 M5 Released - now with CRUD generation and XFire support

2007-05-23T17:49:10-06:00

The AppFuse Team is pleased to announce the release of AppFuse 2.0 M5! This release marks a milestone in the features of AppFuse 2.x. This release adds CRUD code generation, full source support (just like 1.x) and XFire integration. In addition, we've fixed all the issues related to switching persistence frameworks, and you should now be able to easily switch from using Hibernate to to iBATIS or JPA. The videos have been updated for M5. The Easy CRUD with Struts 2 video shows how code generation currently works.

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

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. Maven for Newbies might also be useful if you've never used Maven before. There is some support for Ant in this release.

For more information, please see the 2.0 M5 Release Notes. If you'd like to use AppFuse offline (or download everything at once), you may want to grab the dependencies and extract them into your ~/.m2/repository directory.

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)

Comments and issues should be posted 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.

Update: The videos are much lower quality than the ones I originally recorded (13 MB vs. 70 MB). If you want to view the high quality videos (they're much clearer), you can download them from java.net. If someone has a better way to compress these (I just used QuickTime's Export feature), please let me know.

Also, this release contains the first release of the AppFuse Maven Plugin. This plugin is largely based on Hibernate Tools. We modified many of the FreeMarker templates from Hibernate Tools to default to certain annotations, as well as clean up the formatting. These templates are currently available in AppFuse's SVN. Hopefully making them available is enough to satisfy Hibernate's LGPL license.

What web framework are you using with AppFuse?

2007-04-25T11:05:04-06:00

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!

2007-04-21T17:27:33-06:00

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:

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

2007-04-21T10:22:32-06:00

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?

Comparing Java Web Frameworks: Proposed Outline

2007-04-17T09:13:22-06:00

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?

2007-04-16T12:40:45-06:00

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.

AppFuse 2.0 M4 Released

2007-03-24T16:33:21-06:00

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.