Re: proposed update of log4j stuff....

I'm not sure if anyone is actually using Barracuda on Servlet-2.2, but 
would it be worthwhile to leave the 2.2-required stuff in web.xml but 
commented out? That way, the 2.2 folk can easily see what they need to 
change in web.xml.

Just a thought...
-shawn

Christian Cryder wrote:
> +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
> 
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda