avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Logger package
Date Tue, 27 Mar 2001 23:22:07 GMT
At 02:49  27/3/01 -0800, Harmeet Bedi wrote:
>I think it would be useful to apply the idea of programming for
>replaceability in the context of logger functionality.

Ages ago this used to be the idea. But it was decided that logging (along
with classloader, security, threading) were system level services and
should not be pluggable by the application.

>Logger could be a block(possibly 1st block) with configuration information
>of log targets.

this used to be the case but it was found to be lacking. It didn't really
offer anything and every block had to have a dependency on the block etc.

>If that is problematic, then
>- that points to a weakness in Avalon. The component manager approach
>is good but a global component registry would make it easier esp for code in
>migration towards blocks. LogKit acts as a globally available registry of
>loggers that ComponentManager does not provide.

Going through LogKit was the old-style interface to get at Loggers. If you
notice none of the Avalon classes actually directly call anything in
LogKit. All Loggers are passed around via org.apache.avalon.Loggable. JAMES
has yet to be fully converted to this model (though will be eventually). 

>- A simpler and maybe a part way step to logger block could to have a
>factory that has different Logger objects as interfaces - Logger, LogKit
>etc. These interface could be mapped to different implementations in
>org.apache.log or org.apache.log4j. 'org.apache.log' could be trivial and
>done first and after that if someone wants 'org.apache.log4j'.

That would be a 3rd API that is 
- either just as complex as logkit or lacks in features
- slower than any of the other toolkits

I don't see the advantage in that ;)

>I find org.apache.log easier to follow, but log4j seems to have more
>features and mindshare. Either way both seem good. My only problem is that I
>need to learn about 2 log implementations. That sucks, but is definitely
>better than 0. :-)

Log4j has more features and mindshare - true. However Avalon doesn't
need/want most of the extra features that log4j offers. The useful ones
(logging to sockets/DB/jms/NT) would be easier to port across.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message