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). 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:[EMAIL PROTECTED] 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, > > 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 - 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]
