----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, June 05, 2002 11:40 PM Subject: Re: PROPOSAL: Consistent logging ( for 3.x, 4.x )
> On Wed, 5 Jun 2002, Bill Barker wrote: > > > At least in 3.3 land, I'm leaning to Remy's opinion. It's going to be > > painful. However, I'm +1 (i.e. I'll help on the 3.3 stuff) . As Remy > > points out, TINA. > > Ok, what does 'TINA' mean :-) ??? There Is No Alternative (© Margaret Thatcher :) > > I see your point, I'll play a bit more with the class loaders ( I'm using > log4j in common ). > > In JDK1.4 we don't have the option to move the logging in > the container loader :-), and at least log4j can be upgraded in common > at any time, not only when you upgrade the VM. > > > > 3.3.1 as recommended on the Coyote download page (tomcat-util.jar is in > > common, and commons-logging.jar is in container). Now, commons-logging is > > pretty stable, so I don't have a problem with (like in 3.3.2-dev) putting it > > in common. However, I really don't want to put log4j.jar in common since > > then it would over-ride the one in WEB-INF/lib. This is almost as bad as > > putting JAXP in common. > > > I'll try to get it in container. It should work, except the messages that > are displayed before the logger is set up ( where the 'default' of > commons-logging will be used ). > > > What I'm worried about is setting up the per/context loggers and where > they'll write. I assume webapps using log4j will provide their own > configuration, but how do we mix this with the global settings ? And > how do we deal with the sandbox. This is a little farther down the road. I'm guessing that the replacement for LogSetter will probably have to include an option(s) to control merging. For the first shot, I'd go for "use webapp configuration", since people who currently have log4j installed would have to have setup the file anyway. > > > Fortunately ( or not ) JDK1.4 logger doesn't seem to care about security, > so why should we worry ... :-) > > Ok, it'll be more painfull than I thought - but still we should do it, > it's a mess. > > > My first thought was to move o.a.t.u.log back to jakarta-tomcat, and convert > > the rest of o.a.t.u.** to commons-logging. But this still has the same > > problems..... > > > Now that recycling is working again, I'm very fond of qlog. I'd like to be > > able to keep it as an option (as a plugin to commons-logging). > > Long term I think o.a.t.u.log should be deprecated. I agree qlog is a nice > ( and quite efficient ) piece, so maybe it can be turned into a > common-logging logger ( and so available to other apps ). +1 > > The last thing we need is yet-another logging API ( o.a.t.u.log is > probably older than most others, but that doesn't matter ). > > Costin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
