At 05:31 PM 3/27/2004 +0000, you wrote:
The tiny web-applications Hello and Tata demonstrate how multiple web-apps can live in separate logging contexts.
Here are the installation steps to run the examples.
Steps performed on the Java Web Server (Servlet Container) =========================================================
- Place log4j-VERSION.jar, where VERSION is 1.3 or above, in your web server's (YES, server's) shared class loader directory.
For example, for Tomcat versions 4 or 5, that would be common/lib/, for Resin version 2.1.x that would be the lib/ directory under the Resin installation folder. Other Servlet containers such as Jetty also have folders for shared jar files.
Will things break if this doesn't happen? That is, if there is a log4j.jar in WEB-INF/lib in any given webapp, do things no longer work? It should work either way. As Yoav always stresses, application dependencies should be kept with the webapp in WEB-INF/lib to maximize portability. Of course, using a repository selector in this case under Tomcat is overkill. However, other servers behave differently in how they load classes. A repository selector would be needed under JBoss or Weblogic whether one included log4j.jar in WEB-INF/lib or not since they both include Log4j at a higher level and don't seem to enforce servlet-spec recommended classloading behavior for webapps, so Log4j in the parent classloader is used in preference to the one in WEB-INF/lib. But, then again, there is no guarantee that any particular appserver uses Log4j, nor does one always have control over what classes get added to the appserver's system classloader. The only guarantee is what you decided to put into WEB-INF/lib, so this stuff needs to work whether log4j.jar is in WEB-INF/lib or in a shared classloader.
BTW, what if different versions of Log4j are in the server and the webapp. Any clashes? Again, this is difficult to control in an environment you don't own.
- When launching your java web *server*, make sure to add the log4j.repositorySelectorClass system property on the java command line.
For the JNDIContextSelector the exact system property to add is:
-Dlog4j.repositorySelectorClass="JNDI"
Again, if you control the server, this is great. However, not all developers control the server environments. Is there a backup plan here such as the way my InitShutdownController works in logging-log4j-sandbox where it installs a repository selector if one doesn't already exist? This way, if one has no control over the server environment, a repository selector may still be used.
- You can now run the supplied web-applications hello.war and tata.war.
Steps performed per web-application ==================================
- In each web-application's web.ml file add a JNDI environment entry for the log4j logging context name. For the "Hello" web-application this takes the following form:
<env-entry> <description>JNDI logging context for this app</description> <env-entry-name>log4j/context-name</env-entry-name> <env-entry-value>hello</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry>
See also the file examples/tiny-webapp/Hello/src/WEB-INF/web.xml
- Include a log4j.properties or log4j.xml configuration file in your web-application's WEB-INF/classes directory.
This file will be automatically taken to configure the repository instance specific for your web-application.
This is great, except that I keep log4j.xml out of WEB-INF/classes for the specific reason that I gather some info at runtime and set those as environment variables before performing configuration (done via a servlet context listener). Is this still something that will continue to work, even with your changes?
Note that you will need log4j-VERSION.jar to compile the
web-applications but log4j-VERSION.jar file should not be included
within the web-application's jar file.
Like I said above, this is not very enforceable nor necessarily a wise thing to do, so things should work whether log4j.jar is in the server's classpath only, in WEB-INF/lib only, or in both. If not, Logj4 will be too fragile for production use. I'll see if I can test out your sample webapps and verify some of this for myself and let you know if I find any quirkiness.
Jake
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
