Skip to main content

Is GlassFish a development or a deployment platform?

4 replies [Last post]
Joined: 2003-06-13

There has been an interesting stream of comments in this forum topic and this bug report:

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!



Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-10

My personal take on this: development AND deployment platform.
Already a P2 bug ( is filed for better log reporting. Feel free to enter new bugs related to your experience and they will be evaluated.
These can be filed either on GlassFish or a related Tools.
If you know some other better implementations that are both developer friendly and deployment ready, it would be good to know as well.

As you have seen, Tools support is coming (NetBeans Java EE 5 branch) and now Eclipse.


Joined: 2003-06-10

Let me dive a little bit more on the logging/error messages report.

Yes we know that error reporting is not always perfect, with international team, folks can be challenged with english or just put messages plainly is difficult.

I have for instance put a lot of effort in the annotation processing tool to give meaninful error messages with the offending symbol and the location. However when processing class files, we don't have line numbers so things are not always that easy. Location can be the class declaration, field or annotated method.
We don't stop processing annotations until there are more than 100 errors but that did not help Cay who did not have the annotation and it got picked up by TopLink code.

I am very interested in enhancing the error reporting but we also need more concrete examples because even as the glassfish architect, if I send an email asking to review error messages, my feeling is that very few people will do it better than last time.

So, we want to get there, help us by either providing patches or specific instances of grossly misrepresented error messages. We all make stupid mistakes as Cay mentioned, hopefully we kind of all do the SAME ones... let's build on that


Joined: 2003-06-13

Well, I am glad that there is a consensus for "both".

I have a question about line numbers. During development, I compile with debugging info on, in the hope of getting better stack traces.

Can't you get the file/line# info in that case? I realize it may be a bit of a pain, but I do think it needs to be done. After all, GlassFish must be able to tell the IDE "I found this error, and the best place to report it is in file X, line# Y."

I'll start collecting my stupid errors, and I'll report back once I have critical mass. Won't take me long at the rate I am going :-)


Joined: 2003-06-13

Ok, I got started with this. Whenever I get another cryptic error message, I'll add a report to

The more I look at this, the more I question whether server.log is a reasonable place for communicating errors to the developer. (It is a fine place to deposit error messages when a fully debugged application is deployed, but that's another story altogether.)

There ought to be a place where the various GlassFish components can deposit messages to the developer. Those messages ought to contain the file name/line# of the offending source file whenever possible.

When an application dies, then those error messages--and not the useless stack trace with the RemoteException--should be displayed in the browser window, the console, or the IDE error window.