RE: proposed update of log4j stuff....

+1 from me on this. Looks like a very easy change to apply...basically, all
we need to do in our applications is

a) use the new jar files that contain your new and improved code

b) update web.xml files to reference Log4jApplicationWatch instead of
Log4jInit and change the way we pass the configuration params in

If that's all there is to it, I'm all for it...

Nice work!
Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jacob Kjome
> Sent: Wednesday, January 15, 2003 12:26 AM
> To: [email protected]
> Subject: [Barracuda] proposed update of log4j stuff....
>
>
>
> Hi everyone,
>
> I have made some changes to the way the log4j stuff works in Barracuda in
> my local CVS repository.  I want to commit the stuff, but it
> requires some
> changes that might kick people in the butt for a bit if they
> don't realize
> the change happened.
>
> Basically I did the following.
>
> 1.  Got rid of Log4jCRS and replaced it with
> ContextClassLoaderSelector.  The reason for this is that the
> Log4j project
> has accepted a version of my repository selector in the next version of
> Log4j (1.3).  However, after review by those smarter than myself,
> the class
> was significantly simplified and the name was changed.  I want to
> keep the
> same naming scheme so that the only thing that changes when
> Log4j-1.3 comes
> out is that we change the package reference in the init code to point to
> the log4j package instead of Barracuda's package.
>
> 2.  Moved the init stuff into the contextInitialized() method of the
> Log4jApplicationWatch servlet context listener.  This makes the logging
> setup more bulletproof.  It guarantees that logging will be configured
> before any code in the app uses log4j where the servlet init does
> not.  Also, I was able to remove the ugly syncronization code since the
> code is guaranteed to be called once, and only once in the entire
> application lifecycle.  I actually did keep Log4jInit around, but
> it should
> only be used in servlet-2.2 environments.
>
> 3.  Given #2, I had to move the logging config stuff in the web.xml to
> <context-param>'s rather than servlet <init-param>'s because <listener>
> elements don't provide for listener-specific init parameters.
>
>
> Changing this means that people need to be diligent about not using both
> Log4jApplicationWatch *and* Log4jInit at the same time.  Like I said,
> Log4jInit should be removed entirely except for those running under
> servlet-2.2 engines.  Log4jApplicationWatch is all you need for
> servlet-2.3
> engines.  Also, if you update barracuda-webapp.jar, then you also need to
> update barracuda-log4j.jar because of the change of the selector name to
> ContextClassLoaderSelector.
>
> I'm supplying my changes in a zip file (attached).  Let me know what you
> think.  if this change seems ok to make, I'll commit it sometime
> tomorrow.  See Usage.txt inside the zip file for further instructions.
>
> thanks,
>
> Jake