cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [RT] Logging in 2.2
Date Wed, 05 Jan 2005 23:25:15 GMT
> We are not using logkit: we are using Avalon Logger, and the default 
> configuration shipped with Cocoon use the LogKit implementation of 
> Avalon Logger (you say the same below).

true

>> Why do we really need logkit? I honestly don't know.
> 
> 
> Because it's not bloated?

well ...I think keeping an abstraction layer
is not a bad idea. But the question which one
to use... so this would be more about
commons-logging vs avalon logging vs UGLI.

As for the abstraction layers I cannot really
say which one of those is more bloated than
the other. But since we a lot of components
are already relying on commons-logging the
question is whether is makes sense to get
rid of another dependency.

For 2.2 we have jdk 1.4 as a requirement
so we *could* ship without *any* logging
implementation ...and everyone could just
plug in what ever he wants.

That's one thing...

> Your proposal omits an important point: why do we use IoC loggers? The 
> classical way of getting a Category in log4j is to use :
>    private static Logger logger = Logger.getLogger(Blah.class);
> 
> That leads to a topological organization of logger hierarchies (it's the 
> class name) whereas IoC-style logger the way we do it using the "logger" 
> attribute allows for a functional organization of hierarchies, as we can 
> group logs of related components into a single category whatever their 
> class name, thus easing filtering.

...if you chose to get the logger from the class.
Which you don't have to do.

But you are right. I probably the most important
question is: do we need or do we want IoC style
logging.


> - I certainly don't want to start again something similar to the 
> migration from Loggable (logkit-specific) to LogEnabled (not talking 
> also of Composable to Serviceable).

I hear you ...such big changes *are* a PITA.
And we need see whether it's worth it. For
me I see UGLI being ruled out until someone
can provide a good reason to switch. As
already being pointed out - we still need the
isBlaEnabled stuff with it. No matter whether
in source code or added at build time.

So I see it like that:

commons-logging
  o one dependencies less
  o not IoC
  o potential classloader issues(?)

avalon logging
  o nothing to change
  o IoC

...I am not a friend of IoC-logging anymore.
But whether that's worth the change? Don't know...

cheers
--
Torsten

Mime
View raw message