On Thursday 06 January 2005 00:43, Gianugo Rabellino wrote:
> On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
>
> <cziegeler@apache.org> wrote:
> > In the past we had several arguments about why logkit is better and so
> > on but I think most of these arguments are not valid any more.
>
> Well, AFAIU a big one still stands true: security. I really hate the
> idea that other code can write to my channel just by doing a
> Logger.getLoggerFor().
There is also a slight issue with Log4J in its dealings with runtime
dependencies and classloading that may hurt future efforts in Cocoon in "true
blocks".
Ex, If I have a running instance and decides to change the Log4J configuration
to include an Appender that has an additional runtime dependency (javamail
for instance) than is available from the Logger classloader (which they
recommend to be the most top level CL one can manage to put it in), then you
will need to bring down the entire server.
This is the result of missing separation of interface and implementation,
missing classloader strategy and total lack of IoC, and during Merlin days we
were trying hard to stop depend on LogKit and make a full port to Log4J, but
the work seemed overwhelming and the Log4J folks were a bit lost of why this
is a problem for long-running applications.
I also agree with Nicola's pointer of the problems with commons-logging, and
to use it, you will need to throw away the factory and use your own IoC
pattern, but then, that is essentially same as the current Logger
interface...
Maybe just throw away (Abstract)LogEnabled and do constructor injection
instead. Or even relegate Logging to an ordinary service, which is looked up
like any other component.
Cheers
Niclas
--
---------------
If you want the rainbow, you gotta put up with the rain.
- Steven Wright
+---------//-------------------+
| http://www.dpml.net |
| http://niclas.hedhman.org |
+------//----------------------+
|