Robert,
As a developer using Log4j, my expectation is that my configuration will be the
ONE. If I'm using classes that also use Log4j I do not expect that they will do
any reconfiguration on me. If they need to be configured, or if they have
special configuration needs, I would want documentation and a sample config file
so I could put that configuration into my config file. I would expect that the
subsystem not have any very special needs. (for example, an xml config file
should not be required)
For example, I am using Log4j in my web application, and I'm using some
barracuda classes that also use Log4j (as you know) I have one log4j.properties
file. The barracuda logging (in my version) doesn't try any of it's own
configuration but just picks up mine. This is what I expect. When I found
barracuda log statements in my log file I simply changed the
org.enhydra.barracuda category priority to WARN, and I no longer get the
barracuda log messages.
Regards, Will
----- Original Message -----
From: "Robert Leftwich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 10:08 PM
Subject: Multiple components configuring log4j (Warning - long(ish) post)
> I have a question on the best way to handle configuring log4j when multiple
> sub-systems/components each are using log4j. For example, if you use Struts
> and Cactus in addition to your own code then there are 3 different users of
> log4j that may require specific things to be setup at configuration time,
> for example custom categories/category factories.
>
> My thinking is that in each sub-system configuration, you only address
> things that are specific to that particular sub-system,. That is, you
> follow a naming convention to minimize name clashes, such as
> SubSystem1_ConsoleAppender. You only set priorities and appenders for the
> specific sub-system categories, e.g.
> log4j.category.org.subsystem1=DEBUG,SubSystem1_ConsoleAppender and never
> set global things like rootCategory, ending up with a structure along the
> following lines :
>
> SubSystem1
> SubSystem1_Log4jConfig.xml (if custom categories are used) OR
> SubSystem1_Log4jConfig.properties
>
> SubSystem2
> SubSystem2_Log4jConfig.properties
>
> ... etc
>
> However, if you only address things that are specific to a particular
> sub-system in the configuration file for that sub-system (which is probably
> a good thing), how do you handle the case where the sub-system is used in
> isolation and you want to setup some global defaults, such as rootCategory
> logging ? One possible solution would be to use the command line
> -Dlog4j.configuration= method or you can initialize these global things
> from your own code directly or via a configuration file loaded by your own
> code or even better would be letting the default log4j initialization take
> care of that issue.
>
> One problem with this approach that springs to mind is those people that
> want all the log4j configuration in one place and not spread over multiple
> files. How would you tell the sub-system not to do it's initialization? If
> the sub-system used custom categories would a reasonable approach be to
> check to see if one of those categories was already defined in the list
> returned by Category.getCurrentCategories() and then only initialize if it
> wasn't yet defined?
>
> On another tack, it appears the only way to handle custom categories in a
> safe, extensible manner is to use the DOMConfigurator, is that correct ?
>
> TIA
>
> Robert
>
>
> ---------------------------------------------------------------------
> 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]
