This has got to be the single least understood
and frustrating (for me at least) part of Log4J --
eliminating duplicate logs. I can't explain why
I should be getting duplicates in the scenario below.
I am using an XML file with the DOMConfigurator
with this snippet of XML:
<appender name="STDOUT" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%d{HH:mm:ss.SSS} %-5p [%t] - %m\n"/>
</layout>
</appender>
<category name="com.mypackage">
<priority value="fatal" />
<appender-ref ref="STDOUT" />
</category>
<category name="com.mypackage.util.test">
<priority value="debug" />
<appender-ref ref="STDOUT" />
</category>
Now, when I use getInstance() for the util.test
class above and do:
category.log(Priority.DEBUG, "hello");
I see 2 identical lines of logging:
12:57:32.200 DEBUG [main] - hello
12:57:32.200 DEBUG [main] - hello
I give up -- why?
Yes, I hear that parent appenders are "inherited"
but I was asking to log at DEBUG level on the child, and
tracing through Log4J showed me that the appender
for "com.mypackage" was also logging, even though
it was set to Priority.FATAL.
A log at DEBUG level would not have logged if done
directly against the parent category, so why should
it happen indirectly through the child?
How do I do what I want to do, namely establish
a parent logging only FATAL or WARN with individual
children logging DEBUG. This has got to be the
singular most popular thing to try.
This is of course Log4J 1.1.3
Respectfully frustrated,
... ron
-----Original Message-----
From: Don Taylor [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 26, 2001 4:28 AM
To: LOG4J Users Mailing List
Subject: Re: Some "basic(?)" questions
You are correct in stating that you cannot log until you've called one
of the configurator's configure() method. Until then, log4j simply
isn't initialized.
During initialization the category classes will be initialized. That's
the beauty of Singletons. Remember that these cached categories you're
talking about are simply *references* to a Singleton category object.
So there's no harm done in getting a reference before the object is
actually initialized, since there's only one instance of that object in
the system.
I want to clarify what happened when you say the child category logged
it's messages twice. Are you saying you saw two entries in the same log
file, the log file you modified the Appender to use before adding it to
the child category? I hope you say yes! :)
Likewise, I would also expect that the parent category is now logging
to this new file also. Correct?
If you take a quick peak at the Category source then you'll see what's
going on. Each category maintains a list of appenders. When you got the
appender from the parent category you got a reference to the parent's
appender. You then shoved that reference into the child's appender
list. So the child and parent each have a reference to the same
appender object in their appenders list. When you go to log with the
additivity set, they will log to all the appenders in the child's
appender list and then move on to the parent's and so on. Since a
reference to the same appender object is in both lists, you got two
messages. When you set the additivity off you stopped the traversal to
the parent's appender list. So then you only got the one message.
-- Don
--- MiChAeL xEnAkIs <[EMAIL PROTECTED]> wrote:
> Don -
>
> Thanks for the feedback. Yeah, I was already working w/ the
> frameworks
> which led me to these questions.
>
> When referring to a "generic" Category, my meaning was that, for
> instance,
> when the cached (static) Category(s) are first instantiated, they
> are, well
> not "generic", but filled w/ whatever the default properties would be
> -
> which I'm not sure what those are. I was aware that only a single
> instance
> of a Category will exist for a particular Category name, I just got
> thrown
> off by the definitions being included w/ the declarations of the
> static
> variables, though I shouldn't have.
>
> Of course, I never considered just what other configuration occurs
> during
> the .confingure() method (and it sounds that no logging can actually
> occur
> till that happens... is _that_ true?) Given that, the examples could
> just
> have well put off the calls to .getInstance(...) till after the
> .configure()
> call w/out any adverse affect.
>
> Which all leads into another question that came up while fiddling
> today. Do
> Appender(s) conform to the same "rule of thumb" in terms of
> uniqueness,
> i.e., will their only ever be a single Appender instance for a given
> Appender name? If so, does this span all Appender sub-classes (I'm
> guessing
> yes)? I ask as I had some test code which pulled an Appender from a
> Category, created a new child Category, changed the fileName
> attribute for
> the Appender and then set it as the Appender for the new child
> Category.
> When I logged, I was suprised to see the messages logged twice, i.e.,
> the
> child Category logged to its Appender as well as the Appender
> inherited from
> its parent which, apparently, are both the same Appender. Setting
> additivity on the Category remedied this... and now I know.
>
> tanks
> mx.
>
> ----- Original Message -----
> From: "Don Taylor" <[EMAIL PROTECTED]>
> To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Thursday, October 25, 2001 5:08 AM
> Subject: Re: Some "basic(?)" questions
>
>
> >
> > --- MiChAeL xEnAkIs <[EMAIL PROTECTED]> wrote:
> > > Hey all -
> > >
> >
> > <snip>
> >
> > >
> > > I'm wanting to go the route of configuring the logging framework
> via
> > > the XML "properties" file w/ the following reservations:
> > >
> > > When looking through the example code provided, I notice that the
> > > example-classes each have static Category vars which are _the_
> > > categories used for logging (which are declared and defined w/in
> the
> > > declaration statements). However, these classes also include
> calls
> > > to BasicConfigurator<or a subclass>.configure() or
> .configure(String
> > > configFile). As I understand, the Log4J framework will maintain
> the
> > > instances of the various categories such that separate calls to
> > > Category.getInstance(<instance-name>) will _always_ return the
> same
> > > instance for that particular name.
> > >
> >
> > Yes. If you call Category.getInstance() with the same class/string
> > name, you'll get the same category. The examples are simply caching
> the
> > result since there is a hashing performance hit for calling
> > Category.getInstance() repeatedly for the same category.
> >
> > > Now, as I also understand it, when a class is first referenced,
> its
> > > static var's are instantiated at that time. For the sake of
> > > argument, assume that I have static Category object defined for
> each
> > > class _and_ my .xml properties file provides the actual (full)
> > > definitions for these, i.e. including the Appender definition,
> file
> > > locations, etc.
> > >
> >
> > Ok.
> >
> > > So, up to the point of my calling the "appropriate" .configure()
> > > method, the static Category for each class will be just a
> "generic"
> > > Category, yes?
> > >
> >
> > Not sure this matters. Until log4j is initialized you can't do any
> > logging anyway. I'm not sure what you mean by a "generic" category.
> >
> > > Also, when .configure() is called, will the current "generic"
> > > Category definition(s) be replaced w/ those in the .xml
> properties
> > > file (thereby ensuring a single Category instance for each
> > > <instance-name>)?
> > >
> >
> > In your way of thinking, yes.
> >
> > The best way to evaluate log4j is to try it out. Go ahead download
> it,
> > create the scenario you've just described and make sure it works as
> you
> > expect. If you have problems then, we'll be better able to help you
> > out.
> >
> > -- Don
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make a great connection at Yahoo! Personals.
> > http://personals.yahoo.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
