Hmm ... then this is a good candidate for the most often used anti-pattern. Is there anything in checkstyle for it?
Dennis Byrne >-----Original Message----- >From: Martin Marinschek [mailto:[EMAIL PROTECTED] >Sent: Sunday, February 19, 2006 04:57 PM >To: 'MyFaces Development', [EMAIL PROTECTED] >Subject: Re: svn commit: r378805 - >/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/ApplicationFactoryImpl.java > >wo-ow. > >it's great to learn a new thing every day ;) > >regards, > >Martin > >On 2/19/06, Simon Kitching <[EMAIL PROTECTED]> wrote: >> On Sun, 2006-02-19 at 20:27 +0100, Manfred Geiler wrote: >> > On 2/19/06, Simon Kitching <[EMAIL PROTECTED]> wrote: >> > > Just a warning to all developers: when using commons-logging in a >> > > library, STATIC fields must **NOT** be used to store Log objects. >> > > >> > > The problem is that the class may be called with various thread-context >> > > classloaders (TCCL) set. However the class is only ever loaded once. >> > >> > Never heard of that. Simon are you really sure? >> > I think the opposite is true. Containers tend to have Classloaders >> > that all have there own set of loaded classes. So you get problems >> > when your applications Classloader holds some Classes that the >> > container itself has already loaded. Then you get such things like >> > "incomptible class" Exceptions and NoClassDefFound when a class in >> > your webapp is linked to another class in your app but the Loader >> > finds the containers class first. >> >> Yes, I'm really sure. >> >> Here's the relevant paragraph from the user-guide for the upcoming 1.1 >> release [written by me]: >> http://jakarta.apache.org/commons/logging/guide.html#Developing%20With% >> 20JCL >> >> This is not about class compatibility issues; using instance members >> rather than class members doesn't change the classpath/classloader/etc. >> >> It's about the fact that when the field is static, there is only *one* >> Log instance for that class but multiple webapps are using it. Once >> constructed, the Log object simply points directly to a *configured* >> object within the underlying concrete logging library. That underlying >> object therefore either: >> (a) has no webapp-specific state (ie is initialised via config info >> associated with the container not a TCCL) >> (b) has the state of the first webapp that initialised it (ie is >> initialised via config info located via the TCCL active when the Log >> object was created). >> >> Option (a) occurs if the first call to the class is from the container >> itself, or if the concrete logging library used is in a "shared" >> classpath, or if TCCL-based configuration is not enabled in >> commons-logging. In this case, using a static Log is actually ok. >> >> Option (b) occurs when TCCL-based configuration is enabled, and a webapp >> is the first to access that class. >> >> The latter case is the usual one, resulting in logging output generated >> *as a result of webapp B calling MyFaces* ending up in the logfiles for >> *webapp A*. Not good. >> >> Any logging library that attempts to direct output from shared classes >> into the logfile of the webapp *it is running on behalf of* will have >> this issue. Log4j doesn't have this problem by default, as it doesn't >> attempt to put output from shared classes into webapp-specific logfiles. >> However it *does* have an optional mechanism to do this: the >> RepositorySelector. >> http://www.qos.ch/logging/sc.jsp >> If the "Contextual Repository Selector" approach is used as documented >> in the above page, then exactly the same benefits and problems occur in >> log4j as in commons-logging; logging by shared classes goes into the >> relevant webapp logfile [good] but static Log objects in shared classes >> can output to the wrong logfile [bad]. >> >> Avoiding static Log instances in potentially shared classes is the only >> reliable solution. >> >> And as I mentioned in the earlier email, static fields in shared classes >> should be regarded with great suspicion in *all* cases, not just >> logging! >> >> >> Regards, >> >> Simon >> >> > > >-- > >http://www.irian.at > >Your JSF powerhouse - >JSF Consulting, Development and >Courses in English and German > >Professional Support for Apache MyFaces >
