At 05:41 PM 1/14/2005, Jacob Kjome wrote:
I'm speaking of "endorsed" in a slightly different sense. Not physically
endorsed as having been added to the endorsed classloader repository. The mere
fact that they are meant to be core Java or J2EE libraries qualifies them, in
my interpretation, as "endorsed". The reason I say this is that the server
requires access to these libraries and with classloader hierarchies, putting
something like mail.jar in WEB-INF/lib can cause all sorts of classloader
headaches, especially with child-first classloading behavior such as Tomcat
implements.
Tomcat does NOT ship with mail.jar. That is an easily verifiable fact. I do not know of other App server's that does. If log4j-(core).jar is in the server's class path, and mail.jar has not been placed next to it (and if this cannot be changed), then the user wishing to use SMTPAppender has to put mail.jar and log4j-smtp.jar in WEB-INF/lib/. Her only alternative is to put log4j-(all).jar in WEB-INF/lib/ as well, but that will cause her to lose the advantages of putting a single log4j-(core).jar in the server's class path.
[cut]
I'm not sure any spec can solve the issue. In order for an application server
to provide J2EE services, it needs access to these "endorsed" libraries. If an
app provides it in WEB-INF/lib, how is the server supposed to be in command of
the libary when it is in a child classloader. Think of a webapp providing
servlet.jar in WEB-INF/lib. This is meant to be part of the container or Java
itself, because it's not just the webapp that needs it, the server does too.
What is one to do? I think JBoss has tried to solve this using the Unified
Classloader, but I'm sure that has its problems too.
Quoting http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html
As mentioned above, the web application class loader diverges from the default Java 2 delegation model (in accordance with the recommendations in the Servlet Specification, version 2.3, section 9.7.2 Web Application Classloader). When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking. There are exceptions. Classes which are part of the JRE base classes cannot be overriden. For some classes (such as the XML parser components in J2SE 1.4+), the J2SE 1.4 endorsed feature can be used (see the common classloader definition above). In addition, for the following class patterns, the classloader will always delegate first (and load the class itself if no parent classloader loads it):
javax.* org.xml.sax.* org.w3c.dom.* org.apache.xerces.* org.apache.xalan.*
[cut]
Trimming down the size as much as possible could be of benefit to those users
sensitive to jar size, although we'll have to evaluate how big the difference
is to see if it is worth the bother. In the end, though, the idea of
distributing "endorsed" libraries in WEB-INF/lib is not tenable (causes lots of
problems on lots of appservers) so the only reason for splitting up jars in
Log4j is for reducing jar file size.
Would you at least agree that splitting log4j.jar by dependency will not create any new problems but may solve problems that exist already?
Jake
-- 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]
