<snip>
> >> Will this help in logging messages to same logfile in an appserver
> >> environment ( message: "Multiple JVMs writing to one log file"). For
> >> the
> >> same reason, i've used the static initializer to configure the logging
> >> environment. Does this approach have any flaws?
>
> Well yes. It is like owning an automobile but pushing it on foot out of
> fear of wearing the tires. I fail to see the logic.
Well, I can see several (and judging by the others who have done something
VERY similar to myself, I guess they see the same/other reasons):
1.) By abstracting the logging, and by using a LoggingFactory you can easily
return loggers using implementations other than Log4j. For example if you so
wished your factory could decide to use the jdk1.4 logging if the code was
using a 1.4 JVM. Please note that this is just one example - I'm certainly
not advocating jdk1.4 logging over log4j, has I haven't used either
sufficently to make such a judgement.
2.) Using a singleton/static creation interface to do the logging means that
you can configure the logger transparently to the user, and even then only
when required. I can give example code if need be.
3.) You may decide that you want to hide some of the flexibility provided by
log4j in exchange for gaining a uniform use of logging, and to make
programmers life a little easier.
4.) You could use an abstract logging interface to provide additional higher
level functionality. For example we want to use logging to handle 2 types of
log entries - system events (debug statements, assert failures etc) and user
errors/messages which get fedback to the user (e.g. user A saw error B, user
A logs into the system). Both types of errors have different requirements in
terms of appenders so we use 2 seperate categories. Our abstract Logger
class contains methods warn() for system warnings, or warnUser() for user
warnings. The log4j implementation of Logger then uses the relevent
category.
Having been in the position before where I had to change logging toolkit
halfway through a project (due to IBM's strange license for jlog), and
wanting to be able to change an in house solution on my last project (but
not being able to due to the amount of work) I am very much in favour of
this approach. The additonal work to provide the abstraction is pretty
small, as is the loss in functionality, when compared to the advantagesb
outlined above.
Just my opinion of course - I'm sure many of you disagree.
sam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
