geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Stack traces when the start of a GBean fails
Date Fri, 02 Dec 2005 01:24:59 GMT
I used a similar trick in XBean and it worked well.  The problem I  
was having was, as you are starting the server different problems can  
occur, some are fatal and some are not.  In my original code I had  
system exits spread thought the boot code, which made it competely  
untestable.  As soon as I introduced an FatalStartupException, I  
could test the code.  My main method simply call the boot code,  
catches a fatal exception, prints the message, and exits with the  
exit code within the exception class.  IIRC, I set it up so the user  
needs to pass a flag to get the exception stack trace to print.

Anyway,  I suggest we introduce a logical exception hierarchy for  
startup errors, which capture the most common problems such as a bind  
error.  Then the boot code can decide (based on user flags maybe) if  
the error should be treated as fatal.


On Nov 30, 2005, at 3:52 PM, John Sisson wrote:

> Currently if the start of a GBean fails, an error with a stack  
> trace is written to the log.
> Sometimes the cause of the GBean failure is a common user error  
> that does not require a stack trace for the user to rectify the  
> problem.  An example of this is where a port is already in use and  
> we get a BindException.  All the user really needs to be told is  
> that Jetty or Tomcat was attempting to use port x and it was  
> already in use.
> Since BindExceptions are a common problem that new users may run  
> into the first time they start Geronimo on their system, seeing a  
> stack trace IMHO is not a good impression.  I have heard many  
> people comment that they like Geronimo's startup because it doesn't  
> output heaps of unncessary messages.  It would be nice if it still  
> operated that way when users make a common mistake.
> Could we introduce a new exception class e.g.  
> GBeanLifecycleException that can be optionally used by GBeans (such  
> the JettyConnector shown below) and change the code in the catch  
> block of  GBeanInstanceState.attemptFullStart(..) to check if the  
> exception is an instance of GBeanLifecycleException and if so, call  
> the method on the exception that returns whether the stack trace  
> should be logged.
> Comments or other ideas on how we could we improve the current code  
> GBean code so that the start of a GBean can "optionally" result in  
> a message being logged without a stack trace being logged.
> An example of one of the stack traces the user would currently see:
> 09:08:35,375 ERROR [GBeanInstanceState] Error while starting; GBean  
> is now in the FAILED state: objectName="geronimo.server:J2EEAppl
> ication=null,J2EEModule=org/apache/geronimo/ 
> Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebConnector"
> Address already in use: JVM_Bind
>        at Method)
>        at
>        at
>        at<init>(
>        at org.mortbay.util.ThreadedServer.newServerSocket 
> (
>        at 
> 477)
>        at org.apache.geronimo.jetty.connector.JettyConnector.doStart 
> (
>        at  
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance 
> (
>        at  
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( 
>        <SNIP>
> Thanks,
> John

View raw message