Raible Designs

Colorado Software Summit - are you coming?

Are you coming to the Colorado Software Summit this year? I'm excited to go because I wrote new presentations and I think they'll be a lot of fun to deliver. Also, as I've said before, I really enjoy this conference because it's so relaxing. It's a full-week long, which is a tough commitment, but I like to think of it as a vacation. You do have to deliver your talks 3 times each, so you still have to work every day, but there's also a great opportunity to learn from other speakers. And you don't feel rushed since each talk is given 3 times. This means you can treat some days like real vacation days where you only work a couple hours and others you can pack it in and get a brain full of stuff.

Here's my Choosing a JVM Web Framework abstract?

One of the most difficult things to do (in Java web development) today is to pick which web framework to use when developing an application. A few years ago, there were over 50 Java web frameworks available, most of them open source. Since then, the number hasn't gone down, but the quality of choices has certainly improved. Should you use the standard JSF, or something like Tapestry or Wicket? What about Struts' successor ? is Struts 2 better than Spring MVC or Stripes? And what about the slick-looking applications that Flex and OpenLaszlo can create? Should you use Rails on GlassFish or Grails with Groovy? Is ZK really the next best thing? Where does RIFE fit into all of this? The choice hasn't gotten easier over the years.

This session is a discussion about choosing the best tool for the job. Not only will various frameworks and their features be discussed, but so will important factors for choosing a web framework. Is ease of development more important, or future maintenance? Is the project community an important factor? All of these questions will be discussed and answers will be provided. If you are about to choose a web framework, or if you have an opinion about a web framework, this session is for you.

I think it's important to note that this talk is going to be a discussion. I don't plan on offering my opinions as much as I plan on extracting them from others. This talk probably wouldn't work with the Norway crowd (they don't like to participate much), but I think it'll work with the Colorado folks.

If you're attending ApacheCon this year, which talk would you rather attend - Comparing or Choosing? Or maybe "choosing" would fit in better as a BOF?

GlassFish 2 vs. Tomcat 6

In Switched, Dave says:

Now that Glassfish V2 is out I'm switching from Tomcat to Glassfish for all of my development. It's more than fast enough. With Glassfish on my MacBook Pro, Roller restart time is about 8 seconds compared to 16 with Tomcat. And the quality is high; the admin console, the asadmin command-line utility and the docs are all excellent. The dog food is surprisingly tasty ;-)

I did some brief and very non-scientific performance comparisons myself:

Startup Time with no applications deployed:

• Tomcat 6: 3 seconds
• GlassFish 2: 8 seconds

Startup Time with AppFuse 2.0 (Struts + Hibernate version) as a WAR

• Tomcat 6: 15 seconds
• GlassFish 2: 16 seconds

Environment:

• JAVA_OPTS="-Xms768M -Xmx768M -XX:PermSize=512m -XX:MaxPermSize=512m -Djava.awt.headless=true -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseConcMarkSweepGC -server"
• OS X 10.4.10, 2.2 GHz Intel Core 2 Duo, 4 GB 667 MHz DDR2 SDRAM

Since this was a very non-scientific experiment, it's possible the last two are actually the same. It's strange that Dave is seeing Roller startup twice as fast on GlassFish. Maybe they've done some Roller deployment optimization?

I realize startup times aren't that important. However, as Dave mentions, they (and context reloading) can be extremely important when developing.

Update: I got to thinking that Dave is probably referring to context reloading. Here's a comparison of how long it takes for both servers to pick up a new WAR (and start the application) when it's dropped into their autodeploy directories.

• Tomcat 6: 14-16 seconds
• GlassFish 2: 9 seconds

The strange thing about Tomcat is it takes 6-8 seconds to recognize a new WAR has been deployed. Does Tomcat have a polling increment that can be increased during development?

Regardless, it's impressive that the GlassFish guys have made things that much faster for developers. Nice work folks!

These days, I try to use mvn jetty:run on projects. Then I don't have to worry about deploying, just save and wait for the reload. Time to wait for AppFuse 2.0 to reload using the Maven Jetty Plugin (version 6.1.5)? 7 seconds. Of course, it'd be nice if I could somehow get this down to 1 or 2 seconds.

Maybe Dave should use the Maven integration for Roller to decrease his reload times. ;-)

Proposed Tomcat Enhancement: Add flag to escape JSP's EL by default

I posted the following to the Tomcat Developers mailing list. Unfortunately, it didn't get any responses, which means (to me) that no one cares about this feature. I guess the good thing is they didn't veto it.

Hello all,

I'm working for a client that's using a proprietary Servlet/JSP-based framework that runs on Tomcat. They have their own custom JSP compiler and they're looking to move to a standard JSP compiler. One of the things their compiler supports is automatic escaping of XML in expressions. For example, ${foo} would be escaped so <body> -> &lt;body&gt;. JSP EL does not do this. It *doesn't* escape by default and instead requires you to wrap your expressions with <c:out/> if you want escaping.

I'd like to ask what developers think about adding a flag (similar to trimSpaces in conf/web.xml) that allows users to change the escaping behavior from false to true?

I think this is a good option to have as it allows security-conscious organizations to paranoid and escape all content by default.

Thanks,

Matt

Related: http://raibledesigns.com/rd/entry/java_web_frameworks_and_xss

What do you think? Is there anything wrong with adding this (optional) feature to Tomcat? Enhancing security is a good thing - right?

Update: I've entered an enhancement request for this feature and attached a patch.

AppFuse 2.0 Released!

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 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.

AppFuse 1.x uses Ant to create your project, as well as build/test/deploy it. AppFuse 2.0 uses Maven 2 to create your project as well as build/test/deploy it. IDE support is much better in 2.0 because you can generate the IDE project files with Maven plugins. AppFuse 1.x uses XDoclet and JDK 1.4+.

This project was started in April 2003.

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.

AppFuse Light 1.8 Released

AppFuse Light 1.8 adds CSS Framework integration, as well as support for Stripes (1.4.2) and Wicket (1.2.6). It also has significant upgrades for JSF and Tapestry; to versions 1.2 and 4.1.3 respectively. See the Release Notes for more information on what's changed since the the beta release of 1.8.

What is AppFuse Light? Click here to find out.

AppFuse Light is a lightweight version of AppFuse. I was inspired to create it while writing Spring Live and looking at the struts-blank and webapp-minimal applications that ship with Struts and Spring, respectively. These "starter" apps were not robust enough for me, and I wanted something like AppFuse, only simpler.

AppFuse Light is designed to show Java Web Developers how to start a bare-bones webapp using a Spring-managed middle-tier backend and Hibernate for persistence. By default, AppFuse Light uses Spring for its MVC framework, but you can change it to JSF/MyFaces, Stripes, Struts 1.x, Struts 2.x, WebWork, Tapestry or Wicket. In addition, there's a number of extras for Spring MVC, including Velocity and FreeMarker versions, Ajax support and Acegi Security support.

This project was formerly named Equinox and has been under development since April 2004.

AppFuse Light now offers 60 possible combinations for download:

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

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

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

Live demos are available at:

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

Yes, I realize that 60 combinations is ridiculous. I didn't create the frameworks, I'm just integrating them so you don't have to.

Unfortunately, it's a real pain to create Maven archetypes or they'd all be as easy as mvn archetype:create. Rumor is that the archetype plugin will allow you to create-from-project in the future. When that happens, I'll make sure all the combinations are available as archetypes.

Does becoming a committer hurt?

I've recently been offered the opportunity to become a committer on one of the open source web frameworks I often talk about. From a professional and career standpoint, I'd be a fool to turn it down. My clients would benefit and it would look good on my resume. However, I'm wondering if it would hurt how folks perceive me when I talk about web frameworks?

Personally, I don't think it would change my views. Instead, it would probably eliminate my complaining about said framework because its developers would say "If you have a problem with that - fix it!" What do you think - if I were to become a committer on one of Java Web Framework projects, would you still think I'm agnostic when I talk about Java (or other open source) web frameworks? Of course, it's possible you don't think I'm agnostic now, so maybe I'm worried for no reason.

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?

LinkedIn's Office Space

It should be interesting going into LinkedIn HQ next week. Personally, I like the Web Developer's Diner. If you had $50 to decorate your cube, what would you do? I'd buy a few cases and host a BOF (after hours of course).

Spring Web Flow 2.0

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.