You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2005/10/05 03:13:24 UTC
DO NOT REPLY [Bug 35774] -
[logging] TCCL problem in J2EE Container
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