commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Voytenko, Dmytro" <>
Subject RE: logging, TCCL JCL 1.0.5 alpha
Date Thu, 12 Jan 2006 17:59:16 GMT
Hi Robert,

>> the problem lies not in the principle: but in the fact that J2EE
>> classloading is an absolute nightmare. every clever trick known just
>> results in problems in some J2EE container or other and most leak

I'm quite aware of all the issues with class loading, hence the original
request to disable TCCL setup in JCL altogether. That would solve all
majority of the issues. The only inconvinience is that there will be
only one log setup (file) per JVM, unless different log names are output
to different files (as can be setup in LogJ4). It'd be rather
inconvinient, but will work well for a simple configurations with few
applications. The current assumption of parent-last classloading in JCL
doesn't work in many cases anyway.

The only way I see this system work in the current J2EE envirnoment is:
1) Explicitly setup JCL for separate applications (auto discovery of
configuration files doesn't always work in parent-last). This can often
be setup in the common place, such as default web.xml in Tomcat, etc.
2) Runtime log discovery based on TCCL, i.e. having a single "virtual"
Log instance that contains a map of actual Log instances keyed by class
loader (with the week references, of course). I.e. 
	virtualLog.log(...) ==

You can, of course, discard this as 1) more difficult setup; 2) bad
performance comparing to anything available today. But I don't really
see any other way around, hence again, disabling TCCL will do for many


-----Original Message-----
From: robert burrell donkin
Sent: Thursday, January 05, 2006 2:56 PM
To: Jakarta Commons Developers List
Subject: RE: logging, TCCL JCL 1.0.5 alpha

On Fri, 2005-12-23 at 15:37 -0800, Voytenko, Dmytro wrote:

> > Or even better, don't deploy classes in "shared" locations. I
> personally
> > believe this is not good design; applications in a container are
> This is probably the point on which a lot of people can argue in both
> ways. Applications can be independent but still use shared code (in
> case when applications properly defines deployment dependencies). 

the problem lies not in the principle: but in the fact that J2EE
classloading is an absolute nightmare. every clever trick known just
results in problems in some J2EE container or other and most leak memory
during hot deployment. if you can, take some time to read and digest and it's references.

the easiest way to avoid lots of the bad things that can happen is to
simplify your configuration by having *no* shared jars between different
J2EE applications. in many cases, this is also the *only* way to achieve
your goals due to limitations in the specifications. 

the original classloading code in JCL was design by some of the legends
and all the research we mere mortals have done since is that they did
what they could but the specifications involved ensure that this problem
is insoluble. 

if you don't believe me, please, please, please find a way to do it and
then tell us all about it: we'd all be very glad for a solution. or talk
sun into changing the specification so that deep libraries can be shared

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:



Revere provides finance and business professionals with superior data and analytics on companies
traded publicly in the U.S. Our approach is based on precise classification and identification
of key business relationships. The Revere Complete product suite combines the Revere Research
analysis platform and the Revere RealTime market data application. Revere Complete integrates
comprehensive financial and market information - real-time quotes, sector and option analytics,
charts, news, fundamental data, and sophisticated screening - with unique content derived
from Revere's own independent research: 

- The Revere Hierarchy, a patented classification system that provides unmatched detail in
specifying a company's business activities and identifying exact competitors

- Revere Relationships, a database mapping a company to its key competitors, customers, suppliers,
and strategic partners

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message