Raible Designs

Label placement in web forms

From Swapnonil Mukherjee:

Matteo Penzo has published an excellent article about the placement and alignment of labels in data entry forms. His research, though much more scientific and thorough, confirms what I had said earlier, about the importance of right aligning form labels.

In AppFuse 1.9.2, we added support for the CSS Framework and Wufoo-style forms. The new form layout appears to satisfy many of Matteo's suggestions. The only things we aren't doing are: 1) we're using bold labels instead of plain text and 2) we're using labels for drop-downs, instead of making the first element the label. I suppose the bold labels isn't much of an issue b/c we're not using heavy input borders. As for labels and <select> elements, I think the way we're doing things is good enough. If it works for Wufoo, it works for us!

Comparing Open Source Application Servers

With all the recent hubbub about GlassFish, I decided to do a quick performance test this morning. I downloaded all the most recent versions of the various open source application servers, deployed AppFuse 1.9.3 (Struts version) on them, and ran "ant test-canoo" to see if any of them were faster than the other. This was by no means a scientific, isolated test. It also didn't take into account any performance tuning you should do on these servers, I just used the out-of-the-box settings.

I ran these tests on my MacBook Pro (2.16 GHz Intel Core Duo, 2 GB DDR2 SDRAM) with my JAVA_OPTS set to:

-Xms768M -Xmx768M -XX:MaxPermSize=512m -Djava.awt.headless=true

When typing "java -version" at the command line, I got:

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-103)
Java HotSpot(TM) Client VM (build 1.5.0_06-57, mixed mode, sharing)

Servers tested (in no particular order):

• JBoss 4.0.4
• GlassFish B48
• JOnAS 4.7.6
• Resin 3.0.21
• Geronimo 1.1

I'm pleased to note that all servers allowed me to deploy appfuse.war without using a console or command-line tool. They all support dropping the WAR in some sort of auto-deploy directory. Very cool! Secondly, I was able to successfully deploy AppFuse on all of them with no changes to AppFuse nor the server. Quite impressive.

My test consisted of the following:

• Copying appfuse.war into the appropriate directory
• Starting the server
• Running "ant test-canoo" from my $APPFUSE_HOME directory once
• Running "ant test-canoo" 3 times, recording the numbers for each run

Here's what I found:

Since I know you're going to ask about Jetty and Tomcat (the two main servlet-only containers), I ran the numbers on those too. First off, I tried Jetty 6 RC0. No dice - I got the following error when trying to start the server.

java.lang.IllegalStateException: Cannot initialize context because there is already a root application 
context present - check whether you have multiple ContextLoader* definitions in your web.xml!
        at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:173)

Since AppFuse deploys on all the above app servers, as well as Jetty 5.1.x, I'll chalk this up to a bug in Jetty 6. I used Jetty 5.1.11 for this test because I already had it installed on my machine.

I don't know that these numbers mean anything, but it was a fun experiment. For those of you who think these numbers might mean something, here's the rankings:

1. Tomcat 5.5.17
2. Resin 3.0.21
3. JBoss 4.0.4
4. Jetty 5.1.11/GlassFish B48 (tie)
5. Geronimo 1.1
6. JOnAS 4.7.6

Of course, the better test would be hammering each server with 1000 concurrent users (or a number higher than that) and comparing how each server holds up.

AppFuse Roadmap updated for 2.0

I've updated the AppFuse Roadmap for the upcoming 2.0 version. The current plan is to have a few milestone releases before the final 2.0 release. I can't promise any specific release date because of developer's schedules and current commitments. However, my hope is we can have it done by the end of this year.

Milestone 1

• Maven 2 integration
• Migrate from CVS to Subversion
• Remove XDoclet, putting generated files into source tree
• Get all flavors (WARs) deployed and running on Tomcat and Jetty Maven Plugin
• Spring 2.0: Upgrade XML to XSDs, annotations where appropriate
• Upgrade WebWork to Struts 2
• Documentation - move to new Confluence or DocBook-based system for 2.0 documentation

Milestone 2

• JDK 5, Annotations and JSP 2.0
• Archetypes for creating new AppFuse projects
• Documentation, including screencasts for tutorials

Milestone 3

• Integrate XFire by default (for existing classes and generated classes)
• Code Generation/AppGen - hopefully with the AppFuse Maven Plugin
• Documentation

2.0 Nice to haves

• TestNG replacing JUnit
• Hibernate Validation Annotations (hard part is hooking it into the web frameworks)
• Tomcat Plugin for Maven (that operates like Jetty's plugin)
• JPA Support
• Support for JDK 1.4 using something like Retroweaver
• Support for using Ant to build/test/deploy AppFuse-based projects
• Someone to do all the documentation ;-)

Let me know if there's anything that seems to be missing from this list.

If you can't wait until the end of this year, you may take a look at Patrick Lightbody's newly announced Project Able. He has a lot of good ideas in there that I hope to learn from.

Dream Machine

Well done Apple, you've created my dream machine. Too bad it's so damn expensive. My ideal configuration is as follows:

• Two 3GHz Dual-Core Intel Xeon
• 4GB (4 x 1GB)
• Hard Drive - Bay 1: 250GB 7200-rpm Serial ATA 3Gb/s
• Hard Drive - Bay 2: 500GB 7200-rpm Serial ATA 3Gb/s
• 2 x NVIDIA GeForce 7300 GT 256MB
• Apple Cinema HD Display (23" flat panel)
• 2 x SuperDrives
• Both Bluetooth 2.0+EDR and AirPort Extreme
• Apple Wireless Keyboard and Apple wireless Mighty Mouse
• AppleCare
• Subtotal: $6,436.00

The nice thing about owning one of these bad boys is you could run several copies of Linux and Windows (using VMWare and/or Parallels). I could literally buy one machine and have 5 in a matter of hours. Hmmm, I should probably bump up that ram to 8GB.

It's tempting, but that's a lot of cash to shell out for a machine. Then again, the more write-offs the better.

AppFuse 1.9.3 Released

This release is primarily a bug fix release, but also contains upgrades to several dependent libraries, including Acegi Security 1.0.1.

To install and configure AppFuse for development, see the QuickStart Guide. Thanks to all the sponsors who have contributed products and free hosting to the project.

• Download
• Release Notes
• Learn more about AppFuse

To see how AppFuse works, please see the following demos (username: mraible, password: tomcat):

• Struts + Spring + Hibernate
• Spring + iBATIS
• WebWork + Spring + Hibernate
• JSF + Spring + Hibernate
• Tapestry + Spring + Hibernate

Comments and issues can be sent to the mailing list or posted to JIRA.

Note: If you're building AppFuse on Linux, you should be aware of some non-English encoding issues. The solution is to add the following to your ~/.bashrc file.

export LC_CENGINE=en_US
export LANG=en_US
export LANGUAGE=en_US

Seam 1.0

I've posted my thoughts on Seam 1.0 to my Virtuas blog. What are your thoughts?

It's great to see the release of Seam 1.0. Seam is similar to many full-stack frameworks like Rails, Rife and AppFuse in that it gives you all the pieces you'll need to build a kick-ass web application.

I've blogged my thoughts on Seam before, so there's no need to do that again. I like the idea, especially the lack of interfaces and the 3-files-for-each page idea. However, I don't know that this concept will fly with Java developers. I agree there's a need to simplify, but many of us are mesmerized by the de-coupling that Spring gives us. So now we're programming to interfaces, and every-so-often swapping implementations. I don't know that we can switch to this simpler model. And then there's the "EJB" thing. I think there will be a fair amount of developers that don't use EJB3 simply because it has the "EJB" name. The best thing the EJB Expert Group could have done for EJB3 would be to give it a new name.

The other thing I worry about with Seam is that it wasn't developed from an existing application. AFAIK, it didn't get extracted from a real-world application that had all the problems that Seam solves. I know that Gavin is a smart guy, and he's probably seen these problems in the real world, but there's nothing like developing a real-world application with a technology - and then extracting the framework from that.

In reality, I'm probably jealous. Seam has some really cool features, JBoss has done a great job of marketing it, and it seems to be a really cool way to develop applications. If I'm going to make AppFuse a direct competitor to Seam, it's gonna be quite the uphill battle.

RE: Thoughts on the future direction of AppFuse

Sanjiv has some interesting thoughts on the future direction of AppFuse. To summarize: take on Seam head-to-head, but use Spring instead. Get rid of all the other frameworks except for JSF, Spring and Hibernate. Furthermore, focus on making Web 2.0 applications easy to create and use.

I like Sanjiv's ideas, but I'm not so hot on ditching all the other web frameworks in favor of JSF. I'm still not convinced it's the best solution for Java web development. The idea behind JSF is great, but the implementation has warts. Maybe that'll be fixed with JSF 1.2, but it will likely be quite a few months before MyFaces supports it. Yeah, I know there's the RI, but it is an RI and you remember the 1.1 version don't you?

I'd hate to give up WebWork support because I've used it on a couple of projects and really like it. Ditching Spring MVC would likely be a mistake as well since it's the most popular web framework among AppFuse users today. While I love what Tapestry brings to the table, it is harder (for the newbie) than JSF. Also, it seems to be the least-used web framework in AppFuse, which means I'm doing a lot of maintenance for no reason. AppFuse 2.0 will definitely make things simpler (JDK 5, Maven 2, standard directory layout, better IDE integration), but it will still be difficult to support 5 web frameworks and 2 persistence frameworks.

What do you think about Sanjiv's proposal? It sounds good to me. However, I'd rather see different lead developers for each framework and continue to support them all - except for Struts of course.

How do you determine a good MaxPermSize?

I know I'll probably get beat up for not knowing my JVM Turning parameters. I admit that I should know them better than I do. Hopefully this post will help us all understand them a bit better.

Ever since I upgraded appfuse.org to AppFuse 1.9.1, it's been experiencing OOM issues. They've been so bad that the site is lucky if it stays up for more than an hour. I've done a fair amount of performance testing on a single AppFuse application (and gotten very good numbers), so I was pretty puzzled by the whole situation.

To reproduce the problem, I downloaded all 5 demos to my machine and began profiling with JProfiler. Nothing stood out, but I was able to reproduce the problem by clicking through all the different applications. While testing, I had my JAVA_OPTS set to -Xms256M -Xmx384M.

After staring at JProfiler for hours, I gave up and sent my findings to the AppFuse mailing list. After going back and forth with several ideas, Sanjiv came up with the winner.

Did you try increasing the max perm size (-XX:MaxPermSize=256m)? Max Perm size is running out of memory and not necessarily the main memory. Class metadata stuff is placed in the perm memory (google for more details) and since we're using Spring, Hibernate and Tapestry which all use a lot of reflection, proxying etc, it's not surprising that max perm size is running out of memory.

Based on his advice, I added -XX:MaxPermSize=256m to my JAVA_OPTS, fired up JProfiler/Tomcat and began hammering my local instance with WAPT. 15 minutes later, with 20 simultaneous users, the heap and memory were humming along nicely with no issues. I made the change on appfuse.org and it's been up every since.

This experience has motivated me to start adding "-XX:MaxPermSize=256m" to all my JAVA_OPTS. Is this a good idea? If so, is 256m a good value to use? If not, what's the best way to determine (or guess) the proper value for this setting?

[TSSJS] Friday Morning: RIFE and Seam

This is my 2nd day in Vegas and so far this town is treating me fairly well. I haven't lost all of my money, but the $25/hand blackjack tables haven't been kind. Yesterday, I woke up with a glass full of Berocca next to my bed - which means I passed out before drinking it. I needed it too, Matt Filios won a poker tourney and a bunch of us enjoyed "bottle table" (with Kettle One vodka) to celebrate. Spendy and good, but painful the next day.

Last night, I heard it was Crazy Bob's bachelor party, so I went to bed early to avoid the debauchery. Julie and a good friend of mine are flying in tonight, so there will be plenty of that this evening. So after a good night's sleep, I'm up early and attending the conference. The first hour has a lot of good sessions: Introduction to Seam (Gavin), Dive into RIFE (Geert), OSWorkflow (Hani) and Transforming Enterprise Java into a Commodity (Geir).

I'm sitting in Geert Bevin's session titled "Dive into RIFE" and it's a pretty small audience - maybe 20 people. Geert is the CTO of Uwyn, a small custom application development company. He's the founder of RIFE and creator of many RIFE projects: RIFE/Crud, RIFE/Jumpstart, RIFE/Continuations, Bamboo (forum), Bla-bla List (RIA todo list), Drone (Information bot) and Elephant (blog).

What is RIFE? It's a full-stack component framework to quickly and consistently develop and maintain Java web applications.

• Integrated layers allow you to quickly get results with a minimal amount of code
• Best practices are enforced in a pleasant way, providing many additional features and a consistent approach throughout all applications
• Components can easily be resused in many contexts
• Creating maintainable applications is our first goal
• A lot of attention goes to code-level developer comfort
• Frustration reduction by instant changes and reloads
• Creative solutions for difficult problems
• Embraces established standards (XHTML, HTTP, SQL, ...)
• Geared to developing web applications and doesn't abstract away too much
• Everything besides the web engine is designed to be independently usable
• Attention to the whole life-cycle of your application

Geer is now talking about all the different pieces of RIFE - how it has a JDBC abstraction like Spring JDBC, web services support (even publishing of RSS Feeds) and a content management framework. Now we're going to look at RIFE/Jumpstart.

What is RIFE/Jumpstart? It's a source archive that you unzip and run. It makes it easy to start with new RIFE applications and contains everything you need (including Jetty). It has immediate support for more common development environments (X-develop, Netbeans, Eclipse, IDEA and Ant). Geert just showed us a video of getting started with Jumpstart and how you can easily use X-develop to build and deploy the app to Jetty. The Jumpstart application currently uses JUnit, but since the RIFE teams is starting to use TestNG more and more, it's likely they'll change in the near future. RIFE Jumpstart looks similar to AppFuse, except they have the save+reload problem solved - using JVM HotSwapping.

Now I've moved to the Introduction to Seam session. Gavin King is the presenter and the room is packed. It's a big room, so that's saying a lot. Gavin is talking about JSF, how backing beans work and what's in the faces-config.xml. How does Seam compare to J2EE? Much simpler code. There's fewer artifacts (no DTOs). Less noise (EJB boilerplate, Struts boilerplate). More transparent (no direct calls to HttpSession or HttpRequest). It's also much more powerful for complex problems.

JSF is amazingly flexible and extensive. EJB interceptors support a kind of "AOP lite" and EJB3 is a powerful ORM engine. Everything (except for the JSP pages) is unit testable can be tested with JUnit or TestNG. For testing the view layer, Gavin recommends using Selenium.

A backing bean is often "pure glue" and is just noise. Furthermore, it accounts for more LOC than any other component. It doesn't really decouple layers, in fact the couple is more coupled than it otherwise would be. Gavin calls this "wedding cake architecture." These applications look good in the window, but don't taste good when you eat them. I get his point, but have to disagree on the taste of wedding cake. It's always been good at the wedding's I've attended. ;-)

By default, web applications in general do not work in a multi-window application. To make it work, it generally requires a major architecture change. A couple of other areas for improvement in traditional web applications: application leaks memory (not cleaning up session objects) and "flow" is weakly defined. Navigation rules are totally ad hoc and difficult to visualize. How can this code be aware of the long-running business process?

JBoss Seam - what does it do? It unifies the EJB3 and JSF component models. It simplifies Java EE 5, filling a gap. In addition, it integrates jBPM and makes it more developer-friendly. Deprecate so-called stateless architecture. Decouple the technology from the execution environment. Run EJB3 apps in Tomcat or in TestNG or use Seam with JavaBeans and Hibernate. Gavin is using Tomcat for the first time and thinks it's hot-deploy architecture is totally broken. Of course, he usually uses JBoss and never has a problem with hot-deploy. It's interesting to hear this from Gavin, especially since I've heard from others that Hibernate breaks the reloading - and it's not the server's fault.

I'm going to head to another session now, but I did look ahead at some of Gavin's slides. Interestingly enough, the jPBM pageflow definition's XML looks quite similar to Spring Web Flow. Speaking of flows, I heard an interesting comments from someone yesterday after they attended Geert's continuations talk. Apparently, after seeing his talk, they think that RIFE's continuations offer a much more elegant solution to pageflow than these "XML programming" mechanisms.

I tried to go to Hani's OSWorkflow talk, but he was doing Q&A when I walked in. Apparently, he finished 25 minutes early. Then I walked into Geir's talk only to find Dan Deiphouse finishing up an XFire talk. Oh well, there's nothing wrong with having a few minutes to mingle between talks.

[ANN] Equinox 1.6 Released

For a good story of how Equinox helps, see Wayland Chan's Equinox to the rescue blog post.

This release's major new features are Tapestry 4.0 and WebWork 2.2.1 upgrades. In addition, I changed to use Maven's Standard Directory Layout. It makes IDE and using Maven plugins much easier, so it's a natural progression.

This release does not contain Maven support for running the integration tests with Cargo. This is because Cargo still seems a lot more complicated with Maven than with Ant. Hopefully I'll be able to figure out an easy way to get test-all functionality with Maven and Cargo in the next release.

All of the frameworks used in Equinox, as well as its build/test system is explained in Spring Live. A summary of the changes are below (detailed release notes can be found in JIRA):

• Added custom exception page for Tapestry, as well as tapestry-flash.
• Changed birthday date input to use WebWork's DatePicker component.
• Added support for pre-compiling JSPs when building with Maven (on by default).
• Added createDatabaseIfNotExist=true to jdbc.properties.mysql to auto-create the database when using MySQL.
• Changed classes that extend *SpringContextTests to use AUTOWIRE_BY_NAME so more than one instance of an interface is supported.
• Dependent packages upgraded:
  • Cargo 0.7
  • DisplayTag 1.1
  • Hibernate 3.1.2
  • Scriptaculous 1.5.2
  • Tapestry 4.0
  • WebTest build 1168
  • WebWork 2.2.1

Download. For more information about installing the various options, see the README.txt file.

Demos:

• Spring
• JSF
• Struts
• Tapestry
• WebWork

Known Issues: The Tapestry-Flash JAR was built with JDK 1.5 - so you'll need JDK 5 to run the Tapestry version. Howard Lewis Ship said he'd fix this tonight or tomorrow. Also, if you're on Unix, you'll need to run "ant fixcrlf" before you install anything. Finally, downloading dependencies might not work the first time. Running the "ant" or "mvn" command multiple times usually solves the problem.

See the roadmap for what's coming in the next release.