geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
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.

-dain

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"
> java.net.BindException: Address already in use: JVM_Bind
>        at java.net.PlainSocketImpl.socketBind(Native Method)
>        at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
>        at java.net.ServerSocket.bind(ServerSocket.java:318)
>        at java.net.ServerSocket.<init>(ServerSocket.java:185)
>        at org.mortbay.util.ThreadedServer.newServerSocket 
> (ThreadedServer.java:391)
>        at org.mortbay.util.ThreadedServer.open(ThreadedServer.java: 
> 477)
>        at org.apache.geronimo.jetty.connector.JettyConnector.doStart 
> (JettyConnector.java:203)
>        at  
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance 
> (GBeanInstance.java:936)
>        at  
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( 
> GBeanInstanceState.java:325)
>        <SNIP>
>
> Thanks,
>
> John


Mime
View raw message