RE: Barracuda: Patch for Log4jInit servlet

Excellent clarification Jake, Thanks!

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: Tuesday, January 14, 2003 8:45 AM
  To: [email protected]
  Subject: RE: Barracuda: Patch for Log4jInit servlet


  At 07:51 AM 1/14/2003 -0700, you wrote:


    Well, one thing for certain - barracuda-log4j.jar needs to be in the
same
    location as log4j, so in this case, I'd say it needs to go in
common/lib,
    rather than the war.

    Let us know what you find out...
    CHrisitan

  This is not true.  barracuda-log4j.jar simply needs to be in a location
where both log4j.jar and barracuda-log4j.jar can talk back and forth to each
other.  This is because barracuda-log4j.jar contains the repository selector
that we tell logj4 to use.  Once that happens, log4j uses the repository
selector's getLoggerRepository() method to return a logger repository to
apps that request it so Log4jCRS is, essentially, part of the logging api at
this point and must be allowed two way contact between it and the log4j api.
In Tomcat, the shared/lib and common/lib clasloaders can see each other.
However, neither of these classloaders can see the webapp classloader.

  Now, given that the webapp classloader looks to itself first to load
classes (unlike any other classloader which looks to its parent first), if
both barracuda-log4j.jar and log4j.jar exist in this classloader, then
everything is peachy because they can see each other.  No conflicts will
happen even if you have these jars in common/lib or shared/lib since they
will have been already loaded, preferentially, from the webapp classloader.
The only case of conflict would be if either log4j.jar or
barracuda-log4j.jar is in WEB-INF/lib, but not both.  In that case, the
webapp classloader would, preferentially, load the lib that is in
WEB-INF/lib, but then the other lib, outside of WEB-INF/lb (either in
common/lib or shared/lib) woudn't be albe to see the lib in WEB-INF/lib.
Now you get NoClassDefFound exceptions and such.

  In conclusion, you can set things up in one of two ways...

  1.  both log4j.jar and barracuda-log4j.jar in WEB-INF/lib (even if both of
these already exist in parent classloaders)

  2.  both log4j.jar and barracuda-log4j.jar in common/lib, or just put
logj4.jar in common/lib (to satisfy Tomcat's internal logging) and put
barracuda-logj4.jar in shared/lib.  I do the latter since you want to put as
few things as possible in common/lib.  It is just cleaner that way and
Tomcat's internal classes can see common/lib and keeping unnecessary stuff
out of there is always good.

  Note that in the case of #1, the custom repository selector is somewhat
pointless because log4j already has a unique logging environment, but it
still works, nevertheless.

  Jake