commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject RE: logging, TCCL JCL 1.0.5 alpha
Date Fri, 23 Dec 2005 21:32:30 GMT
On Fri, 2005-12-23 at 12:49 -0800, Voytenko, Dmytro wrote:
> 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?


Do you mean that you have a class in a "shared" location with this?
  private static Log log = LogFactory.getLog("...");

The use of static fields for loggers in a class that may be shared is a
known issue and is described in the FAQ. The answer is to *not* use
static fields; make the logger an instance member.

Or even better, don't deploy classes in "shared" locations. I personally
believe this is not good design; applications in a container are meant
to be independent.

Regards,

Simon



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