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
memory
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(...) ==
map.getLog(Thread.currentTread().getTCCL()).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
cases.
Thanks,
Dimitry
-----Original Message-----
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]
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
meant
>
> 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
the
> 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
http://jakarta.apache.org/commons/logging/tech.html 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
effectively.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- ABOUT REVERE -
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
www.reveredata.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
