> >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.
If you are putting log4j.jar in the WEB-INF/lib dir for each app, then the repository selector issue is somewhat moot. You'll have your own copy of log4j. The problem will be when you have the log4j.jar+selectors.jar in the container path, log4j.jar in the web app path, and then you use servlets that initialize a repository selector. That would be a mess. I think that what ever solution is created, it should be very well documented as to the expected uses and configurations. I think that whatever servlet related classes get written should provide enough configuration points to be used in different ways (use selectors or not, use a specific selector, init like tomcat, init like resin, init like servlet 2.4, etc). If we can do this, then many of the container specific questions we get on the user list here will be answered or at least have a document to help users figure out what they need to do. I think we might want to move this discussion to the dev list. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
