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).
signature.asc
Description: This is a digitally signed message part
