commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Voytenko, Dmytro" <dvoyte...@reveredata.com>
Subject RE: logging, TCCL JCL 1.0.5 alpha
Date Fri, 23 Dec 2005 20:49:33 GMT
Hi Simon,

Thanks for the prompt response.

I reviewed the code in the trunc and it looked fine. I'm planning to run
it through the unit tests we have. Unfortunetely, some of the problems
are hard to establish in the Junit environment. I'll probably will
deploy the build to our DEV environment next week to see if it will show
any problems.

>> With the JCL changes currently in SVN, it is believed that JCL will
>> correctly handle most cases without the need to disable TCCL loading.

Unfortunetely none of the changes here address the specific problem I
described in the previous email. I have a test setup that I could send
to  you to help to reproduce the problem. There's really no way to
instantiate an appropriate Log to the shared class (normally in the
shared class-loader) based only on the class's name when this shared
class is invoked from the web-application class (i.e. with TCCL
installed to the webapp classloader). In this case, the first
application that would try to access such a shared class we'll determine
its logging parameters and all subsequent calls from the different
applications will produce logs in the log of the first application. I.e.
the behavior is random in this case. Does this make sense?

Thanks,
Dimitry

-----Original Message-----
From: Simon Kitching [mailto:skitching@apache.org] 
Sent: Thursday, December 22, 2005 3:15 AM
To: Jakarta Commons Developers List
Subject: Re: logging, TCCL JCL 1.0.5 alpha

Hi Dimitry,

On Wed, 2005-12-21 at 16:32 -0800, Voytenko, Dmytro wrote:
> Hi,
> 
> I'm sorry for repeating the subject if it was discussed already, but I
couldn't find an archive search. 
> 
> This email is regarding numerous problems with JCL in
multi-class-loader environments. This seems to be a rather critical
issue. I just got a chance to take a look into changes for JCL 1.0.5
currently in the alpha stage. Unfortunetely, these changes resolve a
very small percent of all the problems associated with TCCL. If I
understand correctly changes mostly targeted to make sure ClassLoaders
are released, thus eliminating memory leaks related to hot deployment.
Other issues (arguably more critical) remain unresolved. 
> 
[snip]
> Such a behaviour is rather confusing and basically jeopardizes any
advantages of configuring LogFactory-s for each TCCL. This also brings
system into the uncertain state. If app1 is redeployed, it's not clear
what will happen to the SharedUtils.log, especially if LogFactory itself
will be weak-referenced (as in 1.0.5). 
> 
> These all problems could be resolved by simply disabling use of TCCL
in the LogFactory. I entered this request in the bug database while ago:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36927
> 
> This problem seems to be rather critical to me, so I was wondering if
you have other plans to resolve these problems, or if you believe the
solution described in the bug report is appropriate. If you're persuing
other ways to resolve the issue, could you please point me to the
documents or bug reports describing them? In either case, do you have
information on when the fix could be released?
> 
> thanks,
> Dimitry E Voytenko

There have been a lot of changes since that 1.0.5 alpha branch. It's
better to look at the SVN trunk to see what's happening with JCL.

The next release is likely to be called 1.1, and contain what's
currently in SVN trunk, or very near to it.

With the JCL changes currently in SVN, it is believed that JCL will
correctly handle most cases without the need to disable TCCL loading.
However I agree that there should be some way to completely disable TCCL
loading if necessary, as you describe in your bugzilla entry. I plan to
implement that sometime in early January (assuming that's acceptable to
other JCL developers).

There is definitely interest in getting the JCL 1.1 release out in the
very near future; see the wiki release plan page for example.
Unfortunately no-one has been able to find the time to put the final
touches together but again I hope that I can get that done in January.

If you can help in reviewing code and testing that would be greatly
appreciated.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


  

- 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message