[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jetty-dev] jetty debug options
|
Jan Bartel wrote:
> Gregw has just pointed out quite rightly that the o.e.j.util.log.DEBUG
> option is something that only applies to the StdErrLog class. If you're
> not using that class for your logging (eg you're using log4j or jul etc)
> then obviously it will have no effect.
>
> I think that should be made a lot more obvious, so nobody is mislead
> into thinking that they're enabling more output from the jetty codebase
> irrespective of the logging mechanism used.
>
> I suggest:
> org.eclipse.jetty.util.stderr.log.DEBUG
that should be org.eclipse.jetty.util.log.stderr.DEBUG
> So as this property only affects the StdErrLog class, then we can't
> use it to configure debug output during the startup phase (because that
> class
> isn't active yet). I still think that the name of whatever property
> we use for this has to make it clear that it is only going to affect
> startup logging, and will work regardless of whatever logger you've
> plugged in.
>
> I suggest something like:
> org.eclipse.jetty.start.log.DEBUG
This could be just org.eclipse.jetty.start.DEBUG
> As both of these are still rather long, then it would be good if gregw's
> suggested mechanism could be applied to alias them for the command line.
> Maybe START-DEBUG and STDERR-DEBUG? Although the irony is that the
> START-DEBUG
> would be actually produced by stderr printlns, and the STDERR-DEBUG would
> be produced by jetty's logging mechanism (which just happens to use
> stderr printlns too).
How about that if -DDEBUG=true or DEBUG=true is passed to start.config
then it will set both
org.eclipse.jetty.util.log.stderr.DEBUG
org.eclipse.jetty.start.DEBUG
to true.
This would be a bit of a special purpose hack in start.jar
cheers