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 perfor
Re: [Hibernate] commons logging
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
Re: [Hibernate] commons logging
Hi Adrian,
Sorry I should have read the jboss logging page through to the end
before posting :-(.
On Thu, 2005-07-28 at 11:43 +1200, Simon Kitching wrote:
> >
> > JBoss also has its own trivial logging abstraction (factory + wrapper)
> > that does not have these problems and allows other logging targets,
> > e.g. JDK logging see the bottom of
> > http://wiki.jboss.org/wiki/Wiki.jsp?page=Logging
>
> Interesting approach. I personally don't like this for several reasons:
> * The logging configuration is stored in a container-level file. That
> means that someone needs container administration access in order to
> change the logging configuration for a component, yes? I think a
> component's logging config should be modifiable by the component's
> administrator.
> * As the page indicates, there is a problem when multiple components
> happen to use the same logging categories. Deploying separate test and
> uat instances must be interesting (or having multiple developers
> trying to deploy their personal versions to the same container). The
> workaround is to define separate Appender objects for each alternate
> deployment URL, and filters to then ensure that the component only
> logs to its associated appender(s). This would seem to work, but it
> isn't very elegant or efficient is it?
> * the logging configuration can't reference any custom Level classes
> or Appender classes or Layout classes defined in the component. If
> this were to be allowed, then you would have bidirectional references
> from the *static* logging info in log4j back into the components which
> would block undeploy.
>
> However if components were just to include log4j.jar in their
> WEB-INF/lib directory you wouldn't need to go to all these complicated
> lengths to work around the problem of having a shared logging
> installation; proper per-component logging would just work. Wouldn't
> that be easier?
This all applies to the first setup described for jboss logging, where
log4j is only present in the container's path.
Later there is a reminder that log4j can be put into the application
("component"), though this does require tweaking jboss' classloader
config info so that local log4j instances aren't ignored.
Why isn't the log4j-in-component approach the recommended approach?
I guess logging is one of those issues where the responsibility for
configuring it depends on circumstances. Sometimes the application
deployer should be responsible for this [eg if there is a dedicated
maintenance team for that application], and sometimes the container
sysadmin should be responsible for this [where monitoring of all apps is
centralised].
Using the RepositorySelector-with-log4j-in-the-container approach is
also documented. However this does suffer from some limitations: as
described above it can't load any custom classes from the application to
define appenders, layouts, filters, levels, etc. or undeploy stops
working properly. This isn't something that is a problem when log4j is
deployed within the component/application.
The last point about redirecting java.util.logging into log4j is
interesting. If it redirects into log4j-in-the-container then all the
same issues listed above apply. If it redirects into
log4j-in-the-component then surely the undeploy problem occurs.
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
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] commons logging
Hi Adrian, Thanks very much for your response. On Wed, 2005-07-27 at 11:46 -0400, Adrian Brock wrote: > Static collections are the root of all memory leak brain deaths. Agreed. And if java provided the ability to attach arbitrary data to a classloader then LogFactory would use this instead of having a static map keyed by classloader and the problem would go away. But it doesn't [yet]. Or if j2ee provided some mechanism for an arbitrary library deployed in the container classpath to associate data with a component then that would also be a viable solution and LogFactory wouldn't have to use a static Map. But neither of these features exist as far as I know. In other words, we're aware of the problem but there doesn't seem to be any way around using that ugly static map when people have deployed commons-logging in the container's classpath instead of the component's. Suggestions for alternative solutions are *very* welcome. > > JBoss now uses a patched version of commons-logging > http://anoncvs.forge.jboss.com:8080/changelog/JBoss?cs=MAIN:adrian:20050609001010 > to fix the memory leaks. The same change was made to commons-logging's trunk in Nov 2004, ie to change the LogFactory.factories map to use weak references for its keys. [NB: this is only activated when commons-logging-optional.jar is in the classpath as commons-logging supports java 1.1 which doesn't have weakrefs]. Unfortunately the use of weak references to the map keys doesn't fix the issue completely. If the logging adapter class is retrieved from the TCCL then there is a chain: * strong ref from LogFactory.class to its factories map * strong ref from a map entry to the LogFactory subclass * strong ref from the LogFactory to the adapter class * strong ref from the adapter class to the classloader which loaded it In this case, using weak refs to the *keys* in the LogFactory.factories doesn't prevent the leak. > > JBoss also has its own trivial logging abstraction (factory + wrapper) > that does not have these problems and allows other logging targets, > e.g. JDK logging see the bottom of > http://wiki.jboss.org/wiki/Wiki.jsp?page=Logging Interesting approach. I personally don't like this for several reasons: * The logging configuration is stored in a container-level file. That means that someone needs container administration access in order to change the logging configuration for a component, yes? I think a component's logging config should be modifiable by the component's administrator. * As the page indicates, there is a problem when multiple components happen to use the same logging categories. Deploying separate test and uat instances must be interesting (or having multiple developers trying to deploy their personal versions to the same container). The workaround is to define separate Appender objects for each alternate deployment URL, and filters to then ensure that the component only logs to its associated appender(s). This would seem to work, but it isn't very elegant or efficient is it? * the logging configuration can't reference any custom Level classes or Appender classes or Layout classes defined in the component. If this were to be allowed, then you would have bidirectional references from the *static* logging info in log4j back into the components which would block undeploy. However if components were just to include log4j.jar in their WEB-INF/lib directory you wouldn't need to go to all these complicated lengths to work around the problem of having a shared logging installation; proper per-component logging would just work. Wouldn't that be easier? > > Your whole argument is just wrong. If commons-logging is really > ready for the big time, it should be useable from infrastructure > software that has to deal with mulitple application contexts > and talk amongst themselves in a dynamic environment. Is "application context" the same as the term "component" that I use? Are you talking here about problems that occur when one component calls directly into another component? If so, I agree that there is currently a problem with this in commons-logging: it can produce class cast exceptions. However this is a different issue. In fact, I was not aware until recently that components could obtain references to objects in other components, and then call them without having the TCCL reset. Possibly earlier commons-logging maintainers knew this but if they did they didn't document it ;-(. Now that this is known it will be addressed. By "infrastructure software" are you talking about situations where the container is effectively extended by putting libraries into the container's classpath? The wiki page addresses this; that is entirely allowable but in this case the container-extension is expected to act as a container-extension, not just a random library, and actively manage commons-logging by ensuring LogFactory.release is called on undeploy. Is there a specific problem with this? > Saying
Re: [Hibernate] commons logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Ebersole wrote: > We are talking about moving to log4j... > [...] Sorry, misread Christian's original reference to a 1.4 JDK appender. - -- 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 iD8DBQFC5/brHuKcDICy0QoRAvcXAKCuOwWAy98ufBZ1Xe9WuuQzsHrlAwCgl/yi fRCjddWYeGlKk7/+Y5Bl/uI= =NQpC -END PGP SIGNATURE- --- 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
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=7477&alloc_id=16492&op=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
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=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] commons logging
Here is the trivial converter :)
public class JDK14LoggingAdapter extends
org.apache.log4j.AppenderSkeleton {
protected void append(org.apache.log4j.spi.LoggingEvent event) {
// super has already validated we are not closed and any
// thresholds have been met...
String loggerName = event.getLoggerName();
java.util.logging.Logger jdk14Logger =
java.util.logging.LogManager.getLogManager()
.getLogger( loggerName );
jdk14Logger.log( convertLevel( event.getLevel() ),
event.getRenderedMessage() );
}
public final boolean requiresLayout() {
return false;
}
public final void setLayout(org.apache.log4j.Layout layout) {
// layouts dont make any sense here...
}
public void close() {
closed = true;
}
private java.util.logging.Level
convertLevel(org.apache.log4j.Level level) {
switch ( level.toInt() ) {
case org.apache.log4j.Level.FATAL_INT:
case org.apache.log4j.Level.ERROR_INT:
return java.util.logging.Level.SEVERE;
case org.apache.log4j.Level.WARN_INT:
return java.util.logging.Level.WARNING;
case org.apache.log4j.Level.INFO_INT:
return java.util.logging.Level.INFO;
default:
return java.util.logging.Level.FINE;
}
}
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Bauer
Sent: Wednesday, July 27, 2005 6:57 AM
To: Hibernate devel
Subject: 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=7477&alloc_id=16492&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
---
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_idt77&alloc_id492&op=click
___
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] commons logging
It's just that nobody had time to look into it. And it might well turn out that the effort of removing the dependency on commons logging is too much for the benefit we'd get. So far I had the impression that nobody wants to bother with logging discussions and I really share that view, so let this thread just die if all are happy with the current situation. 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. --- 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=7477&alloc_id=16492&op=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=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] commons logging
Hi Christian, On Wed, 2005-07-27 at 13:56 +0200, Christian Bauer wrote: > > 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. 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] That doesn't mean that commons-logging is always the best solution. Using a logging lib directly will always be more efficient than going through a wrapper. If jboss always bundles log4j then I can see why jboss would be happy for hibernate to also use log4j directly. However the hibernate product would lose the ability to integrate nicely into other environments such as Tomcat standalone or Spring [if Spring doesn't use log4j] if they go direct to a specific logging library. The ref to the page from my earlier email is: http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak [1] Of course if anyone disagrees with the argument please say so and I will add that alternate viewpoint to the wiki page. I know there are many people out there with far more knowledge of containers that I have. 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=7477&alloc_id=16492&op=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=7477&alloc_id=16492&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
