Re: [Hibernate] commons logging
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
[Hibernate] commons logging
Hi, I was recently informed of this thread about memory leaks occurring on undeploy with hibernate and saw a fair bit of criticism on commons-logging. I have written a counter-argument which is available here: http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak I hope you find this information useful. All feedback on this is very welcome. Regards, Simon --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] commons logging
I was recently informed of this thread about memory leaks occurring on undeploy with hibernate and saw a fair bit of criticism on commons-logging. Btw, it would be great if someone could look into replacing commons logging with Log4j and providing a JDK 1.4 appender for Log4j. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] commons logging
On Jul 27, 2005, at 2:11 PM, Simon Kitching wrote: Did you read the page I wrote? It's saying that provided that hibernate and/or the container (eg jboss) uses commons-logging correctly there's no need to move away from it. [1] I personally don't care about what you wrote... sorry. We are always trying to reduce dependencies in Hibernate and we actually discussed exactly what I mentioned over a year ago. It's just that nobody had time to look into it. Nothing to do with memory leaks or anything. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] commons logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Bauer wrote: [...] I don't see any integration problems without commons logging as virtually everybody is using Log4j. Another solution would be a simple Delegate (implemented dynamically typed) in Hibernate and a configuration option. In the end we could remove one JAR dependency on almost all installations of Hibernate I guess. [...] One thing to consider with using the JDK 1.4 logging implementation is that everyone forced to run on WebSphere Application Server 5.0.x is stuck with a 1.3 JDK. Thanks, - -- Barry Hawkins All Things Computed site: www.alltc.com weblog: www.yepthatsme.com Registered Linux User #368650 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC55CvHuKcDICy0QoRAkwgAJ40NXXMlJ7UO8jpdWHDyjgU4K9xYgCfTXct MAeWo3AwW9HccTrIBtquzvA= =AqOu -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] commons logging
We are talking about moving to log4j... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barry Hawkins Sent: Wednesday, July 27, 2005 8:49 AM To: Christian Bauer Cc: Hibernate devel Subject: Re: [Hibernate] commons logging -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Bauer wrote: [...] I don't see any integration problems without commons logging as virtually everybody is using Log4j. Another solution would be a simple Delegate (implemented dynamically typed) in Hibernate and a configuration option. In the end we could remove one JAR dependency on almost all installations of Hibernate I guess. [...] One thing to consider with using the JDK 1.4 logging implementation is that everyone forced to run on WebSphere Application Server 5.0.x is stuck with a 1.3 JDK. Thanks, - -- Barry Hawkins All Things Computed site: www.alltc.com weblog: www.yepthatsme.com Registered Linux User #368650 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC55CvHuKcDICy0QoRAkwgAJ40NXXMlJ7UO8jpdWHDyjgU4K9xYgCfTXct MAeWo3AwW9HccTrIBtquzvA= =AqOu -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- 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 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
