geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Deployment fail at persistent EJB
Date Thu, 14 Apr 2005 23:26:40 GMT
Gianny Damour wrote:
> On 15/04/2005 4:19 AM, David Jencks wrote:
>> Someone helpfully tried to make the deployer errors less annoyingly  
>> verbose but this is the unfortunate result... they are now 
>> meaningless  and useless.  I believe there is a switch or flag 
>> somewhere to turn  stack traces back on, but I don't know where.  You 
>> should also look in  all the logs in geronimo-1.0-SNAPSHOT/var/log to 
>> see if the trace is  logged somewhere with some useful information 
>> about where the error is  occurring.
>> david jencks
> Two general options flags deal with the verbosity of deployment error 
> messages:
>   --syserr
>        Log errors to syserr. Can be either true or false. The default
>        value is false.
>   --verbose
>        Verbose execution mode. Can be either true or false. The default
>        value is false.
> Do you think that their default value should be true?

To a typical user, a stack trace does not convey much useful 
information. We should be clearer about the cause and provide meaningful 
messages that allow them to fix the problem.

The option to dump the full stacktrace should still be there but only as 
a mechanism for people to debug the deployment process itself.

Perhaps we need two different behaviours: one where we report errors in 
the input data that we detected with enough information to fix them, the 
other where we ran into an unexpected problem and just need to bail.

For example, suppose we get a web.xml which contains two servlets with 
the same name. XML schema validation would fail with a unique constraint 
violation but rather than dump a trace, or even the error message from 
the parser, we should say "you have two servlets with the name 'foo' and 
that's not allowed"

Or if a remote server is down, don't report "IOException: Connection 
Refused", report "Could not connect to server at port 1099 
using JMX: Connection Refused"

This will require more work in the deployers as they need to check for 
common error conditions and handle them. We can do that in response to 
problems reported by users, or gradually do the work up front as time 
permits or contributions come.


View raw message