> Just an observation; when programming for loggin
> capibilities, the inital logger needs to be configurable
> from the outside (config.xml) to allow the end user to turn
> on/off different levels of logging.
Absolutely. Java Logging has its own config, but there are examples that
show how to create your own logger(s) based upon yout own meta data. So we
should not have any problem using the Java Logging mechanism with
config.xml. Also, as we start to do more with JMX, I'd like to see run-time
configuration support, rather than rebuild/redeploy/restart. I'd like the
XML files to be used for initial config, but then be able to affect changes
dynamically at runtime, and even re-write the config files from the runtime
changes.
> That said and done, what needs to follow is a strict
> adhesion to a way in which logging calls are made and what
> information is ultimately pumped out.. with this in place,
> some of the issues around loggin and waht's being pumped
> out, will fall away leaveing the other more critial issues
> as to how loggin is performaed and it's connectio to James
> propper.
> Is there a defined methodology of whne to make call to the
> logger from within code ??
For James code, it uses Avalon Frameworks logging, although the use of
logging is somewhat haphard. For Mailets, the logging is also haphazard,
and all sorts of log information is uncontrollably merged, ranging from
debug/trace information to fatal errors, using the two logging methods
previously noted.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
