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: pass (asf.osuosl.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: logging, TCCL JCL 1.0.5 alpha
Date: Fri, 23 Dec 2005 15:37:45 -0800
Message-ID: <B806BA3BDD0FD54A8CC1D779D7C5518F60AE24@tango.Revere.local>
Thread-Topic: logging, TCCL JCL 1.0.5 alpha
thread-index: AcYICGVBzF6g6mV+TT+AFIaive+u/QAEGTdg
From: "Voytenko, Dmytro" <dvoytenko@reveredata.com>
To: <skitching@apache.org>
CC: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

Hi Simon,

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

Thanks for the advice. I'm defintetely trying not to use static logs,
but unfortunetely there's big number of libraries that do. These include
Spring and Axis (at least as of Spring 1.2.6 and Axis 1.1).


> 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).=20

In either case, just having one shared vendor that uses static logs is
problematic in this case.


Thanks,
Dimitry

-----Original Message-----
From: Simon Kitching [mailto:skitching@apache.org]=20
Sent: Friday, December 23, 2005 1:33 PM
To: Voytenko, Dmytro
Cc: Jakarta Commons Developers List
Subject: RE: logging, TCCL JCL 1.0.5 alpha

On Fri, 2005-12-23 at 12:49 -0800, Voytenko, Dmytro wrote:
> Hi Simon,
>=20
> Thanks for the prompt response.
>=20
> 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.
>=20
> >> With the JCL changes currently in SVN, it is believed that JCL will
> >> correctly handle most cases without the need to disable TCCL
loading.
>=20
> 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 =3D 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


 =20

- 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:=20

- 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
=20
www.reveredata.com


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