At 11:24 03/04/2003 -0800, Craig R. McClanahan wrote:


On Thu, 3 Apr 2003, Thomas Nichols wrote:

[snip]

Why don't you just let the underlying logging system configure itself
based on properties files (log4j.properties for Log4J, logging.properties
for JDK 1.4)?  Then you have zero code dependencies, and only need to
make sure that the correct properties file is visible.  Programmatic
initialization of stuff like this is a lot more painful.

More painful - yes. But it gives me fine control without requiring that a properties file be present. I'm re-examining my reasons for wanting this, but my thinking was to get "default" (no props files found) behaviour that works as I expect. Maybe the advantages of this are illusory :)



The other thing to remember is that, at least for the default c-l
implementations, the object you get directly from Log4J:

Logger logger = Logger.getLogger("com.mycompany.mypackage.Foo");

is the exact same one that is wrapped by c-l:

Log log = LogFactory.getLog("com.mycompany.mypackage.Foo");

so configuration changes on the former will be reflected in the behavior
of the latter (it's just a wrapper).

(Dull thud as penny drops). This does exactly what I was trying to do - though now I'm not so sure it's the best solution...


This is only guaranteed if you're using the default implementations in
c-l.  But, as stated above, I would still avoid programmatic
initialization totally if you can.  Zero implementation-classes is
infinitely better than one :-).

Craig

Thank you for taking the time to explain the options here - a plethora of choices!


Best Regards,
Thomas.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to