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 35774] - [logging] TCCL problem in J2EE Container
Date Wed, 05 Oct 2005 01:13:24 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=35774>.
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=35774





------- Additional Comments From dvoytenko@reveredata.com  2005-10-05 03:13 -------
Hi,

Somewhat related problem with using TCL in the shared environment (Tomcat). For 
instance I have application A (classloader A) and class A1 that invokes class 
S1 in the shared classloader S. Class S1 has static initializer for logger 
(static Log log = LogFactory.getLog(...)). Provided A1 will be the first one to 
access S1, JCL's LogFactory will use instance cached with A classloader and 
will be (possibly) creating logs within the same A classloader. Further if A is 
undeployed, there will be no way to notify S that it's Log instance is not up-
to-date anymore. This would lead to the memory leaks, even if ClassLoader is 
removed from LogFactory's cache. In addition, such situation will be illogical -
 why should child's classloader used for initialization of parent's classloader?

A propose a solution that is a compromize b/w server/client idea and static 
linking would be to have a setting (in the system properties) that would 
instruct JCL to not use TCCL (e.g. org.apache.logging.DISABLE_TCCL). In this 
mode, inspection and cache would be performed in the classloader of the 
LogFactory. This solution will work good for both: shared environments (Tomcat 
or JBoss with UCL) and for deployments with JCL in the WEB-INF/lib.


-- 
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