At 07:49 PM 1/13/2005, Yoav Shapira wrote:
Hi,
> One of the important features in 1.3 is that you no longer have to
> ship log4j.jar in WARs. The idea is to place log4j.jar in your
> server's common/lib or equivalent.
Some servers don't have a common/lib directory or equivalent. It's not
part of
the J2EE or Servlet Specifications, and as such it should not be a major
design
motivation. When people tell me "I put this and that in common/lib and now
it's not working" I basically tell them to package their app as they
should, in
one WAR i.e. all libs in WEB-INF/lib. That's the only sustainable approach to
portability.
I mentioned ./common/lib/ only because that's what many people are
familiar with. However, we don't need the kind of sophisticated class
loader tree as that offered by Tomcat. From log4j's pov, ./server/lib/
./common/lib and ./common/endorsed/ could all be collapsed together.
The file log4j-(core).jar can be put in any place where 'new
javax.naming.InitialContext()' can be invoked successfully. So for
Tomcat that's ./common/lib/, for Resin, it's ./lib/, for Jetty it's
./lib or ./ext/. I am sure other servers have similar directories.
All that said, I'm 0 (neutral) on splitting log4j into its dependencies. I
don't buy the argument that it's important to make the log4j jar small for
either downloading or disk space. The latter especially is cheap. I do buy
the easier develop/compile/test cycle argument that Niclas put forth. But I
don't like JAR soup.
If log4j-(core).jar needs to be put in the server's class loader, then
splitting log4j into multiple jars by dependency is not optional. It
is mandatory. The reasons for this are explained in my original
mail. Now, why would be want to put log4j-(core).jar into the server's
class loader? Here are some reasons:
1) Allow *any* library to use log4j for its logging, e.g Xerces, JDBC
drivers, etc.
2) Allow the application server itself to use log4j without disturbing
logging in the contained web-apps.
3) Allow two or more web-applications to voluntary share the same
logging environment, (other web-apps still get to have separate
environments).
4) Manage multiple logging environments from a single console.
For casual logging the core log4j classes are amply sufficient. Only
people doing "advanced" logging will need to bother with
log4j-<dep>.jar. They can be expected make an effort to place the
required log4j-<dep>.jar files in ./WEB-INF/lib/ or wherever it is
that they need to be put.
It is preferable to propose a single recipe that *always*
works. Having a log4j-all.jar file crates another logical branch which
may sound more convenient. However, placing log4j-all.jar high in the
class loader tree will not work unless its dependencies are placed next
to it.
The deployment recipe is as follows:
1) Place log4j.jar in ./common/lib or equivalent.
2) set the log4j.repositorySelectorClass system property to "JNDI"
3-SMTP) For each application wishing to use SMTPAppender, place
log4j-smtp.jar+mail.jar+activation.jar in that application's
WEB-INF/lib/. If mail.jar+activation.jar are already on the server's
classpath, then there is no need to add them again in WEB-INF/lib/.
3-DB) For each application wishing to use DBAppender, place
log4j-db.jar plus the JDBC driver for your database in that
applications WEB-INF/lib/
3-JMS) For each application wishing to use JMSAppender, place
log4j-jms.jar plus the JMS driver for your database in that
applications WEB-INF/lib/
You get the point...
Yoav
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
