I am an observer at the JSR 314 (JSF 2.0) expert group, whose mailing list is open (but sadly not yet archived—don't get me going...), and we had an interesting discussion about the “project stage” setting. The expert group's efforts to extend this useful setting to other parts of EE don't seem to go anywhere. I can't tell why, because those discussions sadly have not been open. If you believe that an app server should be a developer platform and not just a deployment platform, say so in the blog comments!
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 has 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.