Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: RE: logging, TCCL JCL 1.0.5 alpha
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: "Voytenko, Dmytro" <dvoytenko@reveredata.com>
Cc: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <B806BA3BDD0FD54A8CC1D779D7C5518F60AE10@tango.Revere.local>
References: <B806BA3BDD0FD54A8CC1D779D7C5518F60AE10@tango.Revere.local>
Content-Type: text/plain
Date: Sat, 24 Dec 2005 10:32:30 +1300
Message-Id: <1135373550.4239.5.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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