Raible Designs

Does Struts 2 suck?

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:

JSF

Struts 1

WebWork

Struts 2

Spring MVC

Tapestry

Stripes

Wicket

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

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?

Choosing a JVM Web Framework: Stories Wanted

My last post on choosing a web framework got quite a few comments. Some seemed to like the application categorization technique as a means to narrow the choices. However, others seemed to disagree. So if application categorization is not a good methodology for narrowing the choices, what is?

I think one of the best ways to figure out a good methodology is to find out what people have done to choose their web framework. I'm looking for stories from developers who have evaluated 2-3+ frameworks for a project. I'd like to come up with 3-5 stories as part of my talk to highlight how some teams have chosen their web framework. What were your important criteria? What made you choose the one you did? Was it a tight race between a few of them? Did industry buzz or application categorization play a part in your decision?

Please send any stories you'd like to share to [email protected]. Of course, you can also post your story in the comments - but an e-mail gives it a bit more validity. If you'd like to share your company name, that'd be great, but it's by no means required. I haven't decided if I'm going to prevent all cases as anonymous companies or not. If you do send a story, I'll make sure and ask your permission before I share any of your personal/company information. Thanks!

Choosing a JVM Web Framework

I plan on rewriting my "Comparing Java Web Frameworks" presentation for this year's Colorado Software Summit. Rather than "Comparing Java Web Frameworks", I'm going to make it into more of a "Choosing a JVM Web Framework" presentation. I think this opens it up to more possibilities such as Grails, JRuby on Rails, Flex and GWT.

One of the things I hope to talk about is choosing the right tool for the job. I think there's 3 types of web applications you can develop:

1. Consumer-facing, high-traffic, stateless applications
2. Internal, more desktop-like applications that are stateful
3. Media-rich applications that require a RIA framework like Flex

Once you've decided on which of these you're developing, it's much easier to narrow down the choices:

1. Struts 2, Spring MVC, Stripes
2. JSF, Tapestry, Wicket
3. GWT, Flex, OpenLaszlo

I'm not sure if GWT fits in the RIA category. I'm not sure where Rails or Grails fit either. They more closely resemble category #1 than any other, yet there's a lot of speculation about their scalability. I think if that perception can be changed, they'll fit into the first category quite well. However, I don't think they compete with component-based or RIA because they don't hold state or offer rich-media capabilities.

Sidenote: I find the scalability debate quite interesting. There's a fair amount of propaganda in Javaland that scalability can be achieved with appservers and clustering tools like Terracotta. If this is true, I've yet to read good solid proof of it. Most of the "how to scale" information out there suggests "share nothing" architectures that shard data and applications across several servers. Of course, there's scalability and then there's massive scalability. Can appservers and clustering solve massive scalability like Google and Amazon require?

The 2nd and 3rd categories have someone of a blurry line, so I'm hoping to figure out how to clarify that. There's also a lot of other factors that will go into choosing a web framework. What if you're simply trying to replace a home-grown framework with an open-source one? If you want to keep your backend and all its logic, does it make sense to use something like Seam, Grails, JRuby on Rails or even AppFuse? Probably not - all their wizbang features and CRUD generation doesn't mean much if all you're using is the web framework. Also, if your application requires support for non-JavaScript browsers (for 508 compliance), then GWT and JSF can be easily eliminated. I know that there are many claims that JSF doesn't require JavaScript, but I've yet to see a real-world application developed with JSF that expects JavaScript to be turned off. Progressive enhancement is a requirement by many of my clients these days.

What's your opinion? How can we make it easier for developers and companies to choose a web framework? Is categorizing application types a good technique?

Integrating Struts 2 + JSF + Facelets

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

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

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.

JA-SIG Keynote: Comparing Java Web Frameworks

This morning I did my first keynote at the JA-SIG Summer Conference in Denver. My talk was on Comparing Java Web Frameworks. I told attendees I'd post it here afterwards, so here it is:Download Comparing Java Web Frameworks Presentation (1.1 MB)

In addition, I mentioned my Java Web Frameworks Sweetspots Whitepaper.

Will I be comparing web frameworks at conferences for the rest of my life? Possibly. I've been submitting 2-3 proposals to conferences and it's the only one that keeps getting selected. I'll be delivering it at OSCON, JavaZone, Colorado Software Summit and ApacheCon US.

The Colorado Software Summit wants to have an original presentation - so I may need to drop a framework or two and add in Seam, Grails and GWT. If you are planning on attending one of these talks, which frameworks would you like to see compared?

Related: Comments after I delivered this presentation at ApacheCon EU.

JAR Hell with XFire 1.2.6

I discovered something somewhat disturbing last week. As part of AppFuse 2.0 M5, we added "xfire-all" as a dependency so web services could be supported out-of-the-box. What I didn't know is that xfire-all has transitive dependencies to 40 other libraries, which total 13.4 MB in size. Yikes!

Does XFire take the cake for the most bloated library you can use or are we just including too much (xfire-all vs. fine-grained dependencies)? I tried changing to the recommended Maven configuration and there's still 28 JARs added by XFire.

The WEB-INF/lib directory of a basic Struts 2 + Spring + Hibernate AppFuse application is already 19.2 MB to start. Adding XFire for web services increases the size to 29.2 MB. While disk space may be cheap, some users have noticed "mvn jetty:run" is much slower with XFire (presumably from the JAR processing that happens at startup). Is there an uber XFire JAR we can use instead?

Canoo WebTest vs. Selenium

From a message I sent earlier to the AppFuse user mailing list:

After getting Dojo's DropdownDatePicker working with both Struts and Spring MVC, I've run into a snag:

You can no longer use Canoo WebTest to enter dates in a form.

It doesn't find the form element because HtmlUnit (the underlying browser implementation for Canoo) doesn't understand/render Dojo's components.

For users, workarounds include:

1. Don't write tests for entering data on forms that have required dates.
2. Don't make dates required.

Either way, it seems logical to move to Selenium for UI testing.

What do you think? Are Dojo-based components the future of Ajax support in Java web frameworks? If so, I wish Dojo allowed more "progressive enhancement" features instead of the invalid HTML feature it seems to rely on now. I'm more than willing to support Dojo if that's what AppFuse users want. However, in my experience with Struts 2's datetimepicker, it seems pretty slow. Of course, if I could render my own input element and then add a datepicker next to it, I'd be much happier. AFAICT, the Struts' datetimepicker doesn't allow you to do this, but I could be wrong.

Of course, if Dojo 0.9 lives up to the hype and is much faster - maybe I should quit caring about Hijax and just start writing those Selenium tests?

For users of those "next-gen" Java frameworks (like Seam, Grails and Wicket), what do you use for UI testing? Does Canoo WebTest work for you when you have a lot of Ajax functionality? If not, do you use Selenium or leave UI testing up to the QA folks?

Update: I ended up using jscalendar for both Spring MVC and Struts 2's datepickers. It's simply the best tool for the job. Dojo is too bloated IMO (240K for a datepicker!) for such a small feature. This allows us to worry about getting AppFuse 2.0 out the door without migrating to Selenium first. We will eventually migrate to Selenium (it's a better tool for the job IMO), but probably not until 2.1. The only question is what's the best way to distribute Selenium tests?