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