struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: Logging in MailReader 1.3
Date Thu, 08 Dec 2005 01:30:29 GMT
On 12/7/05, Ted Husted <ted.husted@gmail.com> wrote:
>
> So, if I'm deploying Tomcat 5.5. and compiling MailReader under Java
> 1.5, what do I need to do to adjust the logging level past "INFO".


I don't know the details of how Tomcat 5.5 is configured (and don't have it
on my laptop to check), but *if* you end up defaulting to the JDK logger,
there is a gotcha you need to pay attention to when you configure it.

This is done by editing $JDK_HOME/jre/lib/logging.properties and adding
lines like:

    org.apache.struts.level = FINEST

to get trace-level debugging from every Struts class.  However, there is an
additional uber-limit on the severities that go to the console log -- and
the default limits it to INFO.  Change

    java.util.logging.ConsoleHandler.level = INFO

as well, to whatever the most detailed level you want is.

Which begs the question: Do we still need so much logging in the
> MailReader? It's much easy to debug a web application in an IDE these
> days, and the logging statements tend to complicate the design. I
> wouldn't want to hedge on error handling (MailReader could actually
> use some more), but I don't know if the logging statements help or
> hinder at this point.
>
> To demonstrate logging, we could also do an example in the Cookbook
> application instead, and maybe show using different logging levels and
> such.


+1 on keeping logging in mailreader if it is *not* in the cookbook, +0 if it
is.  I agree with you that logging should not lead you to scrimp on robust
error handling, but it's still a useful technique for the non-IDE user (as
Frank points out).  In addition, there's a whole different logging notion of
tracking business transactions (instead of debugging messages) that we might
want to illustrate instead, either here and/or elsewhere.

Craig

-Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message