At 08:44 21.02.2001 -0500, Sam Ruby wrote:
>Either:
>
>1) We need to make the abstraction for logging independent of Turbine and a
>Jakarta "standard".
>
>2) Standardize Jakarta on a single concrete implementation
>(jakarta-log4j?).
>
>or
>
>3) as you stated, not do logging in reusable components. (YUCK).
Doing nothing, that is option 3, is always a possibility but boils down to ignoring
the problem which at times is the best approach.
Option 2 would be the most favorable to log4j. The log4j package offers a very simple
logging paradigm:
A) Get a named category instance
B) Log a message using the category instance retrieved previously.
Step B can be repeated as many times as desired without redoing step B.
Logging parameters are configured using a configuration file that can be interpreted
at any time, in particular while the application is still running. Thus, using the
same category instance it is possible to log to a file in one configuration and yet in
another configuration it is possible to collect logs in a buffer and send the buffer
as an email message when an error occurs, output the logs to multiple files, to
another server, or to the Unix syslog among a gazillion other targets.
Many projects encapsulate log4j in wrappers. I guess that approach is similar to
option 1. The wrapper is the interface and the underlying implementation is log4j. As
far as I know, Turbine is doing exactly that. However, I don't think Turbine is using
log4j configuration files. In case just let me know if you need any changes made to
log4j. Cheers, Ceki
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
