"Craig R. McClanahan" wrote:
>
> On Sat, 21 Apr 2001, Glenn Nielsen wrote:
>
> > Ceki Gülcü wrote:
> >
> >> One important point to remember is that each
> >> webapp classloader could load a fresh copy of log4j so that each
> >> webapp has its own logging universe. >
> >
> > This would significantly increase the memory footprint required for
> > logging in the JVM. I would prefer that log4j be global.
> >
>
> Log4J is nothing compared to having multiple XML parsers in memory :-)
>
> Actually, it is technically feasible to do this either way -- if you put
> the Log4J JAR file in common/lib instead of server/lib it becomes
> available to the webapps as well. The disadvantage is that the static
> variables really are global instead of once per web app (which they would
> be if each webapp installed its own copy), so they would share the same
> set of Log4J categories, appenders, and so on.
>
Comments about per webapp vs global installation of jar's:
Tomcat 4 defers to the web application ClassLoader first before
loading classes from the parent classloaders, as suggested by the
Servlet 2.3 spec. Bloating of JVM memory usage due to alot of
web applications all having WEB-INF/lib/foo.jar installed could cause
a problem with scaling if there are 100's of web applications installed.
In our use of Tomcat 4 we will be installing all of the most commonly
used taglib jar files and API's in $CATALINA_HOME/lib so they can be shared by
multiple web applications. Of course the customer can always override
this by installing the jar file locally in WEB-INF/lib, but we will try
to encourage them to use the globally installed versions if they can.
Ideas for log4j:
log4j itself could be installed for Tomcat in $CATALINA_HOME/server/lib.
Logging categories, priorities, and destinations could be configured
in server.xml scoped at the Engine, Host, DefaultContext, and Context
levels.
The normal servletAPI log methods would use log4j under the hood.
The Tomcat 4 global log4j instance would not be visible to individual
web applications.
In addition, create a JNDI Factory for log4j so that a logging category
for a web application can be exported to it using a JNDI logging resource
named something like "jndi:/comp/env/log". That resource would only make
available to the web application the few methods needed to determine if
a logging priority was enabled and to log a message at a priority. This
would allow a web application to use log4j without making log4j internals
visible to the web application.
A manager servlet could even be written to allow changing of log priorities
for the web application. And a tag library provided for use in JSP pages.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
