Quoting Yoav Shapira <[EMAIL PROTECTED]>: > Hi, > > > Placing endorsed libraries in WEB-INF/lib is *not* recommended. In fact, > > Tomcat actively avoids loading at least some endorsed libraries from > > WEB-INF/lib (Not sure about all.... maybe Yoav can clarify?). By > > "endorsed", I mean stuff like javax.*, org.xml.*, org.w3c.dom.*, etc.... > > The set of endorsed libraries is defined by where the endorsed classloader > repository is.
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. > For tomcat, the default is $CATALINA_HOME/common/endorsed. > Typically, the use for this is for XML interfaces, though it can be used by a > server admin to override classes supplied with a webapp with the admin's own > version. You can put mail.jar (and activation.jar, and other javax.* jars) > there, the server will load them, it'll be just fine. > Yup > In an ideal world from my perspective, there would be no common/lib or > common/classes at all. There would only be the server's classes and each > webapp's classes. That was the original intent, and is still the spirit, of > the Servlet Specification (and more broadly, the J2EE Spec itself). Web apps > are supposed to be self-contained. However, that has sadly not turned out to > be the case ;( Which is why our efforts in this area are great! > 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. > So back to my original: if we split log4j.jar by dependencies, that's fine, > as > long as there's also a jar containing everything (preferably called log4j.jar > to preserve backwards compatability). (So that's a 0 vote, no +1 but > certainly > no -1... maybe even a +0 because it gives users additional flexibility). > > > I saw that Yoav mentioned that > > jar size is not a factor. You only have to look at the existence of the > > abomination that is commons-logging for evidence to the contrary. > > CL is an abomination, but how is it evidence of any JAR size issues? The API > and full CL JARs are not split because of size, they're split for other > design > reasons. That's not what I meant. I meant that people sometimes don't want to depend directly on Log4j because it would mean they'd have to ship a relatively large jar file with their app, whereas CL is quite small by comparison. I can't point you too specific evidence of this. I just recall seeing comments on this issue from time to time. Actually, one promise of Log4j-1.3 was that the log viewing utilities would be removed from the core jar making the jar size smaller. Unfortunately (for jar size, at least), with all the new functionality being added to Log4j-1.3, the jar size is already bigger than Log4j-1.2.x even though Chainsaw2 is distributed in a separate jar. 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. Jake --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
