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 foo.bar.com 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.

--
Jeremy

Reply via email to