Using Log4j in subsystems

[Paul Glezen <pg...@atdial.net>]

Hi Robert,

Sorry to respond to this a month late.  I'm a little behind in my
log4j-user mail.  When I place log4j in a utility class that will most
likely be used by other (intra-JVM) clients, I take the following
measures:

1. All log4j configuration for the utility occurs in
   a main method or some external testing method.  The
   log4j configuration of a utility class should not
   depend on a particular configuration but rather adapt
   to the callers log4j configuration.

2. Document the dependence of the utility class.  For users
   of the utility class that don't understand log4j, document
   the fact that calling BasicConfigurator.configure() will
   suffice to initialize logging for your utility class.  For
   users familiar with log4j, document the category names used
   by your subsystem so that users can control the extent of
   your subsystem's logging.

Implicit in the above is that for subsystems, log4j configuration is
always left to the subsystem's caller (a test-driving main method if
nothing else).  This will allow your subsystem to get along with other
subsystems that use log4j.

This has always worked for me because it is the main method that
ultimately knows what the appenders and logging priorities should be;
not the utility classes which may be used in a variety of environments -
each of which has a different log4j configuration.

Hope this helps,
- Paul

Robert Leftwich wrote:
> 
> 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: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org

-- 
Beware of bugs in the above code.  I have
only proved it correct, not tried it.
-Don Knuth

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org