Skip to main content

Project Stage and Openness

Posted by cayhorstmann on January 13, 2010 at 7:17 AM PST

One nice thing about JSF 2.0 is that they have taken good ideas from elsewhere, such as the “project stage” concept from Rails. If you set the project stage to ”development”, you get detailed error and warning messages. If you set it to “production”, you get more aggressive caching. Better diagnostics or better performance? The choice is yours, and that is good.

There has been a bit of confusion about the default setting of the project stage. In the expert group's mailing list (which is open but sadly not yet archived—don't get me going...), I argued that the default should be “development”. After all, I am a developer :-)

Seriously, one of the legitimate criticisms of JSF has been that it had a bad out-of-box experience. Make one wrong move, and you get the stack trace from hell. If the default for the project stage is development, you get a nice web page with useful diagnostics (and can still look at the stack trace if you need it). It turns out that several members of the expert group thought that this was the agreed-upon default, but the spec says otherwise. Hopefully this can be fixed in a spec update.

It turns out that Ed Burns, the expert group lead, had fought a tireless fight to get other Java EE expert groups interested in supporting this concept. Yours truly couldn't have agreed more:

CH>  Absolutely. This is something that I have requested for years. An app
CH>  server is a development platform, not just a deployment platform.

Unfortunately, the servlet 3.0 expert group wasn't too keen on it, but us mere mortals may never know why. Ed responded:

Oh do I wish I could share the JSR-315 EG traffic on this topic with
you.  Perhaps you should be on the servlet EG.

No, I should not be on the servlet EG. I should just be able to read their discussions so that I can learn why they are right and I am wrong. To Ed's great credit, he worked hard to make JSR 314 discussions open, and I think it is about time that other JSRs get a clue. Come on—it's servlets, not secret skullduggery about patents and trade secrets...

In the meantime, I'll argue again that the Java EE platform is both a developer platform and a deployment platform, and hopefully some of you can support me in the blog comments.

Right now, expectations for a Java EE app server (or servlet runner) are pretty low. Of course, it needs to run a perfectly formed app, but it is ok to go in a corner and sulk if there is any error.

Can you imagine if the Java compiler worked that way? If you have no syntax error, you get a bunch of .class files. Otherwise, you get a stack trace. Or the JVM? If you have any runtime error, you'd just get a core dump. Oh wait, we've been there. With C++.

So, the point is that developers have the legitimate expectation that the platform makes every effort to pinpoint every error, giving the file name and line number when humanly possible. That's what the compiler does. That's what the JVM stack trace does. That's what Facelets does in JSF 2.

Sadly, if you have an error in a session bean or one of the (still too many) deployment artifacts, you get some mumbo-jumbo that is deeply nested somewhere in the logs. There is no mechanism for bringing these messages to the developer. NetBeans makes a valiant effort at scraping the logs, and sometimes it even succeeds. But when I talked to app server implementors, their response was uniformly “We don't want to slow down the app server”.

That's where the genius of the project stage comes in. Once you realize that the app server has two roles, it becomes ok to slow it down in the development stage and to coddle the developer. The JSF folks found that once they had this concept, they were eager to put it to use. Caching gets in the way of hot deployment—turn it off during development. In the development stage, a <h:messages/> element is automatically added to every page—a brilliant move because it lessens the frustration of a “stuck page”.

So, what's the harm of having an app server setting for the project stage? Initially, it might not get much love. But over time, app server implementors may well realize that they can do all sorts of things to make the developers' lot less dreary, and, looking at JSF, it is likely that they will rise to the challenge.

Related Topics >>

Comments

A few other defaults that I think are wrong...

You have to add the following to web.xml so that Facelets ignores commented out code. I can't think of why it shouldn't ignore comments.

javax.faces.FACELETS_SKIP_COMMENTS true

You have to add the following for h:convertDateTime to not use GMT. Not sure why anyone would want the date time to default to GMT instead of local time. Maybe I'm just not writing internationalized apps so I'm think thinking correctly, but, it seems off to me.

javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE true

Well said. However, I think

Well said. However, I think that a sound and solid error handling is crucial for both development and production mode. I really like Glassfish, but error handling is sometimes really absymal (Tomcat is not better at all). Just right now, I launched a GF instance with an expired security certificate. A severe error is logged and the certificate is dumped, including a meticulous ASCII-artwork of the certificate's binary signature in the style of a full-blown hex editor. The only missing thing is the most important information for replacing the certificate: The path to the key store ;-)