On 12-02-26 08:43 PM, Arne Vajh?j wrote:
On 2/26/2012 7:08 PM, Arved Sandstrom wrote:
On 12-02-26 07:36 PM, Arne Vajh?j wrote:
On 2/26/2012 1:10 PM, markspace wrote:
On 2/26/2012 9:22 AM, Novice wrote:
If so, the next logical step would be to treat all the stuff in the
Common project similarly. If I put all of those classes in package
com.novice.common, then each class would have this:
Logger logger = Logger.getLogger("com.novice.common");
Just as an aside, it's more common to use something like
java.util.logging.Logger.getLogger( getClass().getName() );
instead of a string constant. String constants probably won't be
refactored when a class is renamed or moved to another package. The
above needs no refactoring.
Also:
<http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
This section points out that it's more efficient to use "static" for
the
logger. In desktop apps, that's what I'm used to seeing. However it
also
says that "static" interacts poorly with JEE classloaders, so using
instance variables is the norm in JEE (and w/ Tomcat too).
What does "interacts poorly with JEE classloaders" mean??
Arne
Probably this:
http://wiki.apache.org/commons/Logging/StaticLog
This is a page that's been out there for quite a few years.
As the blurb itself states, this is not a problem with your own code
that you're deploying as EARs. You can use static loggers in there all
you like. I've seen a number of long-running 24/7 J2EE/Java EE apps that
do just that, and they work fine, with perfectly independent logging,
because their own application classloaders take care of business.
I don't get it.
If log4j classes are loaded by the container classloader, then
the apps should share logging no matter whether the refs are
static or not.
Sure it can be a problem sharing logging.
But I can not see what static versus non static refs has
to do with that.
I must admit, Arne, you've got a point. I'd read that commons logging
piece some years back, not too critically I see, and never thought twice
about it. Like I mentioned above, the uses of static loggers I've seen
or employed myself have not caused problems, so I figured whatever they
were talking about was something I might run across at some point, with
3rd party JARS in a shared library configuration, and recognize it if I
saw it.
I just now set up a test case using oc4j 10.1.3.5, where I created a
shared library with a JAR containing a couple of classes with log4j
loggers, one with a static Logger, one with an instance Logger.
This shared library is referenced at runtime by 2 servlets in 2 separate
web apps. Each web app has a slightly different log4j.xml, one allows
the library log statements, one is at a level that filters them out.
I tweaked the code in between various server restarts to ensure that
only the static Logger *or* the instance Logger was in use.
There was no difference between the two. We observe the expected
_undesirable_ behaviour, which is that whichever servlet is hit first,
it's the logging configuration for that web app which is used for both
web apps. *But* regardless of which Logger is in use, static or
instance, we get the same undesirable behaviour.
So I agree with you, after rigorous experimentation. :-) It's nice of
the commons logging folks to point out the hazards of shared loggers;
it's considerably less clear why they thought shared static vs. shared
instance was important.
I think it happens frequently. Someone claims X without investigating
too much. Because X really does not have much practical impact, then
nobody else checks the claim. Instead it get quoted by someone and
another quote that. And suddenly we have an "accepted fact" that