You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by MiChAeL xEnAkIs <x...@ubermind.com> on 2001/10/24 19:24:09 UTC
Some "basic(?)" questions
Hey all -
Just starting to get my hands dirty w/ Log4J and feel like I'm missing some basic points when reading the thru the FAQ, Archives, manuals, et al.
Specifically, at present, I'm looking to setup an application to test the functionality of the logging framework and do a general proof-of-concept to see how it fits in w/ our development process here.
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.
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.
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?
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>)?
Also, in the archive I came across a posting looking for a better reference to explain the DTD for the .xml properties file, but saw no responses. Does anyone have such a reference? Of concern, I notice that the DTD - for all its comments - does not provide explanations for, say, the "Threshold" param on <appender/> or the "Additivity" param on <configuration> (or I think its on <configuration/>, I actually haven't been able to verify this yet.
Soo, errr, any comments regarding my assumptions are, as always, greatly appreciated.
mx.
"When a relationship is not built on mutual respect,
the only way of maintaining control is through brutal force."
-- Roger Fouts
RE: Some "basic(?)" questions
Posted by David Schultz <ds...@atstransportation.com>.
One thing to remember...
If you haven't called the .configure(...), then the first call to
.getInstance(...) will invoke the default initialization. The documentation
has a multi-paragraph discussion of the rules for default initialization.
So, I won't repeat them here. However, the simplest form says that if there
is a "log4j.properties" file in the classpath, then you'll automatically
initialize.
If the auto-initialize can't find the properties file, you get the "dreaded"
;^) Log4J not initialized on your _first_ call to a writing method
(.info(...), .warn(...), etc.), and nothing will be written until you call
.configure(...)
-----Original Message-----
From: MiChAeL xEnAkIs [mailto:x@ubermind.com]
Sent: Thursday, 25.October, 2001 08:17 PM
To: LOG4J Users Mailing List
Subject: Re: Some "basic(?)" questions
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" <do...@yahoo.com>
To: "LOG4J Users Mailing List" <lo...@jakarta.apache.org>
Sent: Thursday, October 25, 2001 5:08 AM
Subject: Re: Some "basic(?)" questions
>
> --- MiChAeL xEnAkIs <x...@ubermind.com> 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: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Some "basic(?)" questions
Posted by Don Taylor <do...@yahoo.com>.
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 <x...@ubermind.com> 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" <do...@yahoo.com>
> To: "LOG4J Users Mailing List" <lo...@jakarta.apache.org>
> Sent: Thursday, October 25, 2001 5:08 AM
> Subject: Re: Some "basic(?)" questions
>
>
> >
> > --- MiChAeL xEnAkIs <x...@ubermind.com> 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: log4j-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: log4j-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Some "basic(?)" questions
Posted by MiChAeL xEnAkIs <x...@ubermind.com>.
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" <do...@yahoo.com>
To: "LOG4J Users Mailing List" <lo...@jakarta.apache.org>
Sent: Thursday, October 25, 2001 5:08 AM
Subject: Re: Some "basic(?)" questions
>
> --- MiChAeL xEnAkIs <x...@ubermind.com> 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: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Some "basic(?)" questions
Posted by Don Taylor <do...@yahoo.com>.
--- MiChAeL xEnAkIs <x...@ubermind.com> 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: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org