So you are saying that webapp developers should ask the following to a Servlet/Filter/Listener destroy function ?
LogFactory.release(getClass().getClassLoader()); "Simon Kitching" <[EMAIL PROTECTED]> skrev i en meddelelse news:[EMAIL PROTECTED] > Hi Adrian, > > On Wed, 2005-07-27 at 20:15 -0400, Adrian Brock wrote: >> On Wed, 2005-07-27 at 19:43, Simon Kitching wrote: >> > I feel that it is simply unacceptable to drop thirdparty libraries that >> > have never expected to be "container extensions" into the container's >> > classpath? >> >> So aren't you just saying don't use commons-logging in infrastructure >> software unless you can isolate that part of the infrastruture >> from sharing any classes with the rest of the server? >> i.e. don't use it an application server like Tomcat/JBoss > > Not at all. I'm saying that any code deployed into the container's > classpath should be container-aware or that the container should be > aware of it or both. > > Tomcat uses commons-logging, and that's fine because Tomcat ensures that > it cleans up commons-logging when an app is undeployed (see > org.apache.catalina.loader.WebappClassLoader). [1] > > If jboss wants to use Hibernate as part of the container, and Hibernate > uses commons-logging then that's fine: but the container needs to take > that into account by ensuring LogFactory.release is called on undeploy. > Yes it would be nice if this wasn't necessary but as I described earlier > neither java nor j2ee provide *any* mechanism for arbitrary code in the > container's classpath to associated resources with a component > ("application context") so commons-logging can't easily do this itself. > > But I think people should *not* expect that they can grab any random > open-source library from the internet, drop it into the container's > classpath and expect things to work properly. Such libraries should go > into the component's WEB-INF/lib unless they are explicitly declared to > be "container extensions". NB: this includes dropping hibernate into the > container classpath of some arbitrary container framework (j2ee or > otherwise). > > Commons-logging only qualifies as a valid "container extension" when the > container ensures that LogFactory.release is called on webapp undeploy. > > One interesting problem with many libraries that use logging is that > they do this: > public class Foo { > private static final Logger log = Logger.getLogger("somecategory"); > } > The problem occurs if the getLogger method uses the TCCL to determine > what Log object to return. In the case of log4j, if the Context > Repository Selector is configured for log4j then this problem occurs. > Commons-logging has the same limitation. > > When such code is in a component's classpath everything is fine. But > when such code is placed into the container's classpath the *first* > component to call it determines what Log object is returned, then when > other components call into that code in the shared classpath the wrong > logger gets used. Again it's back to that static caching issue: using > statics is fine when the class is deployed *via the component* but wrong > when the class is deployed via a shared classloader. > > [1] I noticed another interesting little bit of code in tomcat;s > WebappClassLoader.stop method: > // Clear the classloader reference in common-logging > org.apache.commons.logging.LogFactory.release(this); > // Clear the classloader reference in the VM's bean introspector > java.beans.Introspector.flushCaches(); > The introspector class caches stuff at a global level?? eek! Again this > would be a very nice case for attaching such cached info to a specific > classloader to avoid these kinds of bidirectional links... > >> >> I personally don't like this argument. It would lead to 100 applications >> with 100 copies of Xerces (lots of memory footprint) just in case >> it had a memory leak. > > Well, xml parsing is part of the j2ee spec so this is a different issue > from people tossing any old library into the classpath. > > But if a container bundles xerces then I would expect the container > provider to read the xerces documentation to make sure xerces is known > to be safe in such an environment and that there is nothing extra that > xerces requires in order to run correctly in that setup. As it happens, > I don't know of any such issues but I don't think such assumptions > should be made. See the java.beans.Introspector note above! > > >> And those "applications" in the case of infrastructure couldn't pass >> DOM objects around without serializing/deserializing them. > > Sorry, I don't follow this one. As mentioned above, j2ee servers provide > xml parsers by definition so apps don't (and shouldn't) bundle them. > > Are you perhaps talking about some scenario where: > * there is an interface I1 defined in a shared classpath > * app1 creates a concrete instance of interface I1, using a class > loaded from the local path > * app1 then performs a JNDI lookup or similar to get a reference to > some method of an object residing in app2 in the same JVM, > where that method takes an I1 as a parameter > * app1 then calls that external object passing its local instance > * app2 then caches a reference to the parameter > * app1 then leaks on deploy because app2 has a reference to an object > which has a class loaded from app1's classloader thereby retaining > app1's classloader including all the other classes. > > You know far more about j2ee than I do, so I'll let you tell me whether > this is a common scenario. Certainly ensuring that the implementation of > I1 is in the container's path rather than in the component's path would > solve this. But that whole setup sounds dodgy to me, and rather > unlikely. And pushing up the shared implementation classes into a common > classloader feels more like a workaround for a broken design than a > valid architecture. > > But if this *is* a common usage scenario then I agree I would have to > rethink my posting. > >> >> Hopefully, these problems will go away in JSE7 with a better >> definition of java modularization: >> http://www.jcp.org/en/jsr/detail?id=277 >> > > Hmm..interesting. Thanks for the link. > > Regards, > > Simon > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September > 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
