Is GlassFish a development or a deployment platform?
There has been an interesting stream of comments in this forum topic http://forums.java.net/jive/thread.jspa?threadID=2297 and this bug report: https://glassfish.dev.java.net/issues/show_bug.cgi?id=137
The basic issue is this: If a part of GlassFish finds that an error condition has arisen, and it could with little effort determine that the developer made a silly error, should GlassFish make any effort to alert the developer?
Let's look at a concrete example. I (as an overworked developer) test my app by loading a JSF page. I accidentally type the wrong URL (e.g. index.jsp instead of index.faces), bypassing the FacesServlet. Should GlassFish
(a) show a stack trace with a NPE in
(b) display to the developer a message that a JSF page
was loaded with the wrong URL
The choice (a) is perfectly reasonable if you view GlassFish as a deployment platform, i.e. a "VM for EE apps". A deployment platform need not make any effort to communicate with a developer or with dev tools. It can assume that apps have been fully developed and tested. Any error conditions should be logged, and that's that.
However, in order to be productive, EE developers need more than a "super VM". They need development tools that catch the various errors they make and gives them detailed error messages, complete with file/line# whenever possible.
GlassFish can, of course, only be one part of a development tool chain. I'd like to argue that it should make an effort to be a part. There should be a pathway for GlassFish to give error messages (with file/line#) to a dev tool. When a developer runs GlassFish from an IDE, then the IDE can intercept and display the error messages. Right now, tools integration is just starting, so GlassFish should just show the messages in the browser (and not bury them in the logs).
Well, that's what I think. Let the GlassFish implementors know your opinions!