Yep,
There is no harm in using Log4j within WEB-INF/lib even if Log4j exists in a parent classloader. It doesn't affect any other apps the the current app is free to use whatever version of the jars they want. In the context of using a repository selector, putting log4j.jar in the
WEB-INF/lib is really of little use since it even the default logger repository will be unique to that application only. I just wanted to point out that the custom repository selector, if used by the webapp's configuration, must be in the same location as the log4j.jar and if the log4j.jar is included in WEB-INF/lib, then so must the custom repository selector otherwise you run into weird classloading errors.
So, put log4j in WEB-INF/lib or in a parent classloader. Whatever. Just be diligent about taking jar dependencies into account.
Jake
At 10:35 AM 12/13/2002 -0500, you wrote:
Howdy, >That's a good point. At some point in time, it should be documented >that any container should have one and only once copy of >log4j.jar+associates. Once the selector approach is adopted, putting >log4j.jar in WEB-INF/lib must be strongly discouraged.I agree with the first part, not the second. In my experience, the case of one webapp per container is common (not to mention recommended by some people, for security and other considerations). In that case, I'd say it's not only fine but a good idea to put the log4j core and any optional modules in /WEB-INF/lib. If you're deploying your app in a .war file to heterogeneous servers, this is easier and more portable than putting the log4j files in the (non-standard) common library location in each server. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
