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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
