WebAppClassLoader debug logging verbosity

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

WebAppClassLoader debug logging verbosity

ClintFoster
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
Reply | Threaded
Open this post in threaded view
|

Re: WebAppClassLoader debug logging verbosity

Greg Wilkins
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?

cheers

--
Greg Wilkins<[hidden email]>  US: +1  3104915462   IT: +39 3349267680
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: WebAppClassLoader debug logging verbosity

Stephen J. McConnell
 

> -----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)

I can provide a lot more details if needed.

Cheers, Steve.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: WebAppClassLoader debug logging verbosity

ClintFoster
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)

I can provide a lot more details if needed.

Cheers, Steve.

_______________________________________________
jetty-discuss mailing list
jetty-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: WebAppClassLoader debug logging verbosity

Ceki Gulcu-2
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

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: WebAppClassLoader debug logging verbosity

Greg Wilkins
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.

cheers



--
Greg Wilkins<[hidden email]>  US: +1  3104915462   IT: +39 3349267680
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: WebAppClassLoader debug logging verbosity

Greg Wilkins
In reply to this post by Stephen J. McConnell

Stephen,

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)



> I can provide a lot more details if needed.

--
Greg Wilkins<[hidden email]>  US: +1  3104915462   IT: +39 3349267680
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: WebAppClassLoader debug logging verbosity

Ceki Gulcu
In reply to this post by Greg Wilkins

At 06:14 AM 3/22/2007, Greg Wilkins wrote:

>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.

WDYT?

[1] http://logback.qos.ch/access.html#jetty
[2] http://logback.qos.ch/demo.html


--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss