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:[EMAIL PROTECTED]] 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" <[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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
