commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28291] - [logging] ContextClassLoader may load Log impl from wrong context in JDK 1.4
Date Tue, 15 Mar 2005 17:37:09 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28291>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28291


rdonkin@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




------- Additional Comments From rdonkin@apache.org  2005-03-15 18:37 -------
It's hard to be categorical since there are variations between JVMs. There are known circumstances

where 1.0.4 holds references to classloaders in some containers (but not tomcat) preventing
recycling 
of memory in undeployment. It would not surprise me to find that this is one of those circumstances
(at 
least on some platforms).

If this is a concern, there are a number of actions you might take (any of which should be
effective):

1 If you are going to be hot deploying applications frequently and deploying your logging
systems in 
the child classloader for the web application, then it is a very good idea to add a lifecycle
listener to 
ensure that all logging resources are correctly closed. If you are logging to Log4J, you should
be doing 
this anyway. If you are concerned about releasing references then you should call JCL release
during 
this cleanup.

2 Download the new JCL alpha and install the optional jar. The weak references should allow
the 
memory to be recycled (sooner or later).

3 Reconsider your deployment decision. I'm not sure why you are unhappy to deploy your logging

system in share/lib. Logging systems tend to hold a number of resources open for performance

reasons. Hot deployment therefore isn't particularly pretty for them. There are sometimes
good reasons 
why people are forced to deploy all libraries in the application loader (perhaps because they
do not 
control the container). In other cases, it's worth considering the best deployment strategy.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message