Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
To: tomcat-user@jakarta.apache.org
From: "Bill Barker" <wbarker@wilshire.com>
Subject: Re: FAQ? JDK 1.4 Logging in Tomcat - long and discussive
Date: Mon, 16 Jun 2003 20:38:55 -0700
Lines: 139
Message-ID: <bcm1p3$nbp$1@main.gmane.org>
References: <3EEE5489.5050006@everserve.co.uk>
 <20030617005319.2741.qmail@web40609.mail.yahoo.com>
Sender: news <news@main.gmane.org>


"Yoav Shapira" <yoavs1@yahoo.com> wrote in message
news:20030617005319.2741.qmail@web40609.mail.yahoo.com...
> Howdy,
> You haven't missed something simple.  In fact, I'd venture you've spent
more
> time and thought (and reached better conclusions and solutions) that most
> people who've considered the problem.
>
> Ditch JDK 1.4 logging.  Use log4j.  Everything you want here can be done
using
> log4j's Repository Selector: and it's even done for you for a
webapp/context
> environment such as tomcat in Jacob Kjome's servlet context repository
> selector, currently available in the log4j sandbox and slated for
inclusion in
> log4j 1.2.x.

And I wasted all that time writing a repository selector for TC 3.3 ;-(.
I'll take a look at Jacob's stuff.  It was going to be my next project to
port the 3.3 repository selector to TC 4.1.x/5.x, but if it has already been
done.....

Of course, the same sort of thing could be done for JDK1.4 Logging if anyone
was motivated enough.  Patches are always welcome ;-).

>
> Yoav Shapira
>
> --- Tim Shaw <tim@everserve.co.uk> wrote:
> > Feedback welcome - I've been working on this without much help, and
> > others may well have more experience (which I'd like to benefit from
too).
> > I would love to use a better approach than that described here ...
> >
> > I needed to be able to log my various (multiple-context) web apps. As I
> > couldn't get commons-logging to work with the JDK 1.4 logging, I went
> > the 'direct' route ... and it turns out it wasn't the commons-logging
> > that was the 'problem'. 'Logging' below refers to the JDK 1.4
> > java.util.logging facility ...
> >
> > Most of the stuff on the web just takes you through the api, and shows
> > how easy it is to get logging to work.
> > That's fine - it actually is fairly easy to program to.
> >
> > However ...
> >
> > Running Tomcat, I wanted multiple applications logging to different
> > areas (files and/or db etc), and I started to run into difficult
behaviour.
> >
> > The problem I had was to load my logging configurations into the
> > LogManager - not the mechanism, but the practice. This is a singleton,
> > within the scope of the bootstrap class loader. Consequently, the same
> > object is shared across all contexts (and Tomcat itself). This means
> > that resetting it and then loading an app-specific config file is not an
> > option. Loading an app-specific properties file is an option (via
> > getResourceAsStream), but that has the further restriction that each
> > web-app has to have a distinct namespace (see below). The properties
> > file is not very functional anyway - it specifies defaults for defaults!
> >
> > There is a 'config' option, which allows you to specify a Class for
> > logging initialisation ... but this class has to be accessible from the
> > bootstrap loader (common/lib, shared/lib ... nope! - it's gotta be in
> > jre/lib/ext).
> >
> > Ideally, I would like to be able to supply an app-specific logging
> > configuration file as part of the deployment of my web-app. Potentially,
> > this could be done by loading a data-file from the context and
> > interpreting it to provide the appropriate logging structure (loggers,
> > handlers etc).
> >
> > But ... I have controller servlets in different contexts extending the
> > same class from a 'utility' jar (implementing the Command pattern for
> > Servlets). Most of the code is in the super-class (action class
> > retrieval/activation etc).
> > Following the logging examples, using the class name as the logging
> > context, and making the log variable visible (protected) down to the
> > sub-classes, I end up with multiple log files (logging expands the %u to
> > provide a unique filename when it can't open[?] the file ... I don't
> > even want to guess what it does when the %u isn't given).
> > Additionally, I can't find a way to determine whether the logging had
> > been initialised for a given context.
> > This means that (IMHO) utility classes cannot log!
> >
> > I have ended up by extending the logging.properties mechanism, in the
> > time-honoured way, by adding '.' separated properties for each
> > logging-context :
> > eg <context>.handler.level = INFO
> >     <context>.handler.class = com.xxx.<app>.DBHandler
> > etc
> > These are then added into the (system-wide) logging.properties file, and
> > the Class which interprets them is specified in the config and has to be
> > jar'd into the jre/lib/ext.
> > Additionally, I have removed all logging-system stuff from my utility
> > classes. I only get a Logger when I have a sufficiently unique path to
> > guarantee no conflicts.
> >
> > This gives me the flexibility I need to log multiple apps in an
> > appserver (tomcat) environment ... but I'm not very happy with it. It
> > could be refactored to allow each context's Controller to load their own
> > properties, and then interpret those (on my list of things to do), but
> > this relies on calling a log-initialisation routine ... not something I
> > want to do within 'client' JSP's (which live in another context). I have
> > put JSP's into a different package (component separation - no problem),
> > so the current setup allows me to specify that package as a root for
> > which logging is enabled ... but this would not work without
> > initialisation code unless I used the 'config' class approach.
> >
> > An additional restriction is still that I cannot log directly from the
> > utility super-class. I have to create log variables at the concrete
level.
> >
> > Summary : I don't think jdk 1.4 logging has come of age - it's nice and
> > simple from the API POV ... but in real world usage it's lacking.
> >
> > Please tell me I've missed something simple ;-)
> >
> > tim
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
>
>
> =====
> Yoav Shapira
> yoavs@computer.org
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org