Re: [Hibernate] commons logging

[hv @ F. C. <in...@fa...>]

So you are saying that webapp developers should ask the following to a 
Servlet/Filter/Listener destroy function ?

  LogFactory.release(getClass().getClassLoader());


"Simon Kitching" <ski...@ap...> skrev i en meddelelse 
news:112...@lo......
> 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