logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Watts <...@cliftonfarm.org>
Subject Re: Initializing log4j in a library
Date Wed, 18 Jul 2012 16:27:54 GMT
On Wed, 2012-07-18 at 16:00 +0100, Aidan Delaney wrote:
> Dear all,
> I have a bunch of loosely related class files that I distrubute in a
> single jar.  So, for instance I have Foo.java and Bar.java, where
> there is not top-level init() for the library.  I also want to use
> log4j to replace the antiquated not-quite-logging system that is in
> this code.  I'm wondering what's the best-practice way to do this.
> 
> >From what I can see, it's best to create a ProjectLogger with a
> static initialiser
> 
> public class ProjectLogger {
>   static {
>     Logger logger = Logger.getLogger(ProjectLogger.class.getName());
>     BasicConfigurator.configure();
>   }
> 
>   static void doInit() {}
> }
> 
> Then importing this into each of Foo.java and Bar.java.
> 
> Foo.java:
> 
> import ProjectLogger;
> 
> pubilc class Foo {
>   static {
>      ProjectLogger.doInit();
>      Logger logger = Logger.getLogger(Foo.class.getName());
>   }
> 
> ...
> }
> 
> and so forth.
> 
> This is not pretty as you need the ProjectLogger.init() in each file.
> However, does this concur with best practice?  Or is it a bit insane?
> 
It's a bit insane. :-)  The easiest thing is to put a log4j.xml or
log4j.properties file in the classpath and you're good to go.

See 

        http://logging.apache.org/log4j/1.2/manual.html#Default_Initialization_Procedure

for more details.

You *could* include such a file in the jar (but it's much better keep it
outside the jar).  Be aware that users of your jar can/will specify
their own config file in the classpath that precedes (i.e overrides)
yours (or worse, yours precedes theirs -- which is the main reason to
keep it out of the jar).  So the logging output and destinations could
be different than your shipped configuration.  This is generally a Good
Thing since users should/must have control of these things (so long as
they understand the implications of what they're doing).


Mime
View raw message