WebAppClassLoader debug logging verbosity

WebAppClassLoader debug logging verbosity

If the class path is long, enabling debug logging causes an enormous amount of information to be logged, due to the toString() implementation in WebAppClassLoader. It dwarfs everything else in the log file. I'm not sure if this is possible with the current logging scheme, but I was wondering if there might be some way to specify whether class path debugging is desired or not?

Re: WebAppClassLoader debug logging verbosity

ClintFoster wrote:
> If the class path is long, enabling debug logging causes an enormous amount
> of information to be logged, due to the toString() implementation in
> WebAppClassLoader. It dwarfs everything else in the log file. I'm not sure
> if this is possible with the current logging scheme, but I was wondering if
> there might be some way to specify whether class path debugging is desired
> or not?
>
> Clint Foster
> Axway

Clint,

my thoughts on debug is that it is increasingly USELESS!

We can attach to remote JVMs with jconsole, debuggers or even
just plain old JMX. The source is open, so it is trivial to debug
or even add the odd old fashion println.

Anything with debug statements is probably part of the code that
has been debugged!

My current inclination is to remove almost all debug statements - leaving
only things like Log.ignore(e).

Re: WebAppClassLoader debug logging verbosity

> -----Original Message-----
> From: [hidden email]> [mailto:[hidden email]] On
> Behalf Of Greg Wilkins
> Sent: Friday, 9 March 2007 2:47 PM
> To: Discussion for Jetty development.
> Subject: Re: [jetty-discuss] WebAppClassLoader debug logging verbosity
>
> ClintFoster wrote:
> > If the class path is long, enabling debug logging causes an
> enormous
> > amount of information to be logged, due to the toString()
> > implementation in WebAppClassLoader. It dwarfs everything
> else in the
> > log file. I'm not sure if this is possible with the current logging
> > scheme, but I was wondering if there might be some way to specify
> > whether class path debugging is desired or not?
> >
> > Clint Foster
> > Axway
>
>
> Clint,
>
> my thoughts on debug is that it is increasingly USELESS!
>
> We can attach to remote JVMs with jconsole, debuggers or even
> just plain old JMX. The source is open, so it is trivial to
> debug or even add the odd old fashion println.
>
> Anything with debug statements is probably part of the code
> that has been debugged!
>
> My current inclination is to remove almost all debug
> statements - leaving only things like Log.ignore(e).
>
> What do others think?

It seems to me that logging information in Jetty is less than useful
primarily because all messages are going though a single logging category
and does not leverage logging levels. This result in a torrent of
information as soon as you enable debug messages.

IMO the solution is not to throw away logging messages, but instead to:

a) remove the Jetty Log abstract and just use plain old
java.util.logging (after all, anyone wanting to map into
an alternative logging system can easily do this by providing
a custom log manager - i.e. log management should not be a
jetty concern)
b) make full use of logging category names - specifically, server
messages should only deal with things at the server level,
connectors should have their own log category names, context
objects should have their own names - this means you can easily
configure which channels are enabled
c) make sure that logging channel names are relative to the parent
logger because Jetty does not know and should not know the
runtime context it is operating within - which means that the
server should be supplied with the logging channel that is the
root channel from the servers point of view (i.e. nothing in
jetty should declare the category name other than the default
logging channel provided if a channel has not been explicitly
provided)
d) make full use of logging priorities - error, warning, info,
debug, trace, not just the single priority currently applied
(and this works when you known you that you are running in an
environment where logging channels and priorities are easily
manageable - which is the case is you assume java.util.logging
(or any simple convenience wrapper that is backed by
the java.util.logging machinery)

Re: WebAppClassLoader debug logging verbosity

A well-thought out logging scheme is invaluable for being able to support a large number of users efficiently. I work on a product with many different logging categories of (a la Steve's point b), and this helps us to quickly hone in on the source of problems, even in code that we thought was thoroughly debugged. When you have thousands of users you never know what is going to happen in the field. Connecting remotely isn't always practical due to firewalls, and if you have a first-level support team that is good at reading logs, you can solve a lot of problems before they get to your developers (or at least narrow them down much better first).

I agree with all of Steve's very nicely-stated points. One thing I would suggest, however, is that it might be a good idea to directly use slf4j as the logging API from within the Jetty source code rather than becoming tied to a particular logging implementation. I think the Jetty Log "abstract" (as Steve calls it) will have to be removed because it will interfere with logging by package-based category if it is present as an intermediary. The nice thing about using slf4j as the logging API is that the binding to the logging implementation can be deferred until deployment. This is especially useful for things like Jetty that may be embedded in other applications that already have their own logging implementation. A number of the Apache projects are now using slf4j.

One last thought: I'm about to post another question regarding a subtle problem that we were able to partially isolate using Jetty's logs (even in their current perhaps less-than-optimal state). I mention this only to illustrate that almost any logging is better than no logging. If logging categories and levels are exploited to their potential, it could make debugging even easier.

Clint Foster
Axway

Stephen McConnell wrote

It seems to me that logging information in Jetty is less than useful
primarily because all messages are going though a single logging category
and does not leverage logging levels. This result in a torrent of
information as soon as you enable debug messages.

IMO the solution is not to throw away logging messages, but instead to:

a) remove the Jetty Log abstract and just use plain old
java.util.logging (after all, anyone wanting to map into
an alternative logging system can easily do this by providing
a custom log manager - i.e. log management should not be a
jetty concern)
b) make full use of logging category names - specifically, server
messages should only deal with things at the server level,
connectors should have their own log category names, context
objects should have their own names - this means you can easily
configure which channels are enabled
c) make sure that logging channel names are relative to the parent
logger because Jetty does not know and should not know the
runtime context it is operating within - which means that the
server should be supplied with the logging channel that is the
root channel from the servers point of view (i.e. nothing in
jetty should declare the category name other than the default
logging channel provided if a channel has not been explicitly
provided)
d) make full use of logging priorities - error, warning, info,
debug, trace, not just the single priority currently applied
(and this works when you known you that you are running in an
environment where logging channels and priorities are easily
manageable - which is the case is you assume java.util.logging
(or any simple convenience wrapper that is backed by
the java.util.logging machinery)

Re: WebAppClassLoader debug logging verbosity

Hello all,

This is a bit off topic, but if you are considering SLF4J, you might also
be interested in logback-access which integrates imho very well with
Jetty. I am mentioning logback as logback-classic natively implements
the SLF4J API.

I am using logback-access daily to debug SOAP messages sent to my
server (Jetty+XFire). Logback-access has many other cool features
such as web-pages access statistics exposes as MBeans (JMX). With
logback-access you get all the powerful features of logback but for
*HTTP/access* logs. By powerful features, I mean pattern layout,
HTMLLayout, RollingFileAppender, SMTPAppender, SocketAppender,
DBAppender, filters, and more. I'd be happy to elaborate if there is
any interest.

Also, my apologies if this is too much off topic.

At 08:35 PM 3/9/2007, ClintFoster wrote:

>A well-thought out logging scheme is invaluable for being able to support a
>large number of users efficiently. I work on a product with many different
>logging categories of (a la Steve's point b), and this helps us to quickly
>hone in on the source of problems, even in code that we thought was
>thoroughly debugged. When you have thousands of users you never know what is
>going to happen in the field. Connecting remotely isn't always practical due
>to firewalls, and if you have a first-level support team that is good at
>reading logs, you can solve a lot of problems before they get to your
>developers (or at least narrow them down much better first).
>
>I agree with all of Steve's very nicely-stated points. One thing I would
>suggest, however, is that it might be a good idea to directly use slf4j as
>the logging API from within the Jetty source code rather than becoming tied
>to a particular logging implementation. I think the Jetty Log "abstract" (as
>Steve calls it) will have to be removed because it will interfere with
>logging by package-based category if it is present as an intermediary. The
>nice thing about using slf4j as the logging API is that the binding to the
>logging implementation can be deferred until deployment. This is especially
>useful for things like Jetty that may be embedded in other applications that
>already have their own logging implementation. A number of the Apache
>projects are now using slf4j.
>
>One last thought: I'm about to post another question regarding a subtle
>problem that we were able to partially isolate using Jetty's logs (even in
>their current perhaps less-than-optimal state). I mention this only to
>illustrate that almost any logging is better than no logging. If logging
>categories and levels are exploited to their potential, it could make
>debugging even easier.
>
>Clint Foster
>Axway

Re: WebAppClassLoader debug logging verbosity

Ceki Gülcü wrote:

> Hello all,
>
> This is a bit off topic, but if you are considering SLF4J, you might also
> be interested in logback-access which integrates imho very well with
> Jetty. I am mentioning logback as logback-classic natively implements
> the SLF4J API.
>
> I am using logback-access daily to debug SOAP messages sent to my
> server (Jetty+XFire). Logback-access has many other cool features
> such as web-pages access statistics exposes as MBeans (JMX). With
> logback-access you get all the powerful features of logback but for
> *HTTP/access* logs. By powerful features, I mean pattern layout,
> HTMLLayout, RollingFileAppender, SMTPAppender, SocketAppender,
> DBAppender, filters, and more. I'd be happy to elaborate if there is
> any interest.
>
> Also, my apologies if this is too much off topic.

Ceki,

not too off topic.

If you want to give us a little write up of using logback, then we'd
be happy to put it on the jetty wiki with a link to your main page etc.

Re: WebAppClassLoader debug logging verbosity

I hear what you are saying. I so regret dumping the orginal Jetty
logging mechanism and switching to JCL in Jetty 5. We did have
much of what you discuss below.

Stephen McConnell wrote:
> a) remove the Jetty Log abstract and just use plain old
> java.util.logging (after all, anyone wanting to map into
> an alternative logging system can easily do this by providing
> a custom log manager - i.e. log management should not be a
> jetty concern)

Because of the disaster of JCL, I am very hesitant to try and pick
another winning and go directly to a logging mechanism.

> b) make full use of logging category names - specifically, server
> messages should only deal with things at the server level,
> connectors should have their own log category names, context
> objects should have their own names - this means you can easily
> configure which channels are enabled

I will consider how we could introduce categories of debug rather than
just deleting debug.

> c) make sure that logging channel names are relative to the parent
> logger because Jetty does not know and should not know the
> runtime context it is operating within - which means that the
> server should be supplied with the logging channel that is the
> root channel from the servers point of view (i.e. nothing in
> jetty should declare the category name other than the default
> logging channel provided if a channel has not been explicitly
> provided)

sure

> d) make full use of logging priorities - error, warning, info,
> debug, trace, not just the single priority currently applied
> (and this works when you known you that you are running in an
> environment where logging channels and priorities are easily
> manageable - which is the case is you assume java.util.logging
> (or any simple convenience wrapper that is backed by
> the java.util.logging machinery)

Note that we do use info, warn, debug and verbose debug statements,
so we are at least a little bit towards d)

Re: WebAppClassLoader debug logging verbosity

>Ceki,
>
>not too off topic.
>
>If you want to give us a little write up of using logback, then we'd
>be happy to put it on the jetty wiki with a link to your main page etc.

Hi Greg,

Logback documentation contains several pages discussing integration
with Jetty. There is the "Logback-access and Jetty" page [1] and the
loggback-demo [2] which is geared towards Jetty to a large extent.

You could perhaps reference these documents from jetty's wiki. I think
that would be preferable to duplicating their contents in your wiki.