avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mauro Talevi <mauro.tal...@aquilonia.org>
Subject Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Date Sun, 15 Dec 2002 19:38:35 GMT

Berin Loritsch wrote:

>The framework part, weighing in at a mere 80k uncompressed isn't
>very heavy.  In fact it is fairly minimalistic.
>I agree with the problem of *perception*
you would also need excalibur-logger to get the logger repository 
functionality via the LoggerManager.
actually, what are the reasons to keep framework.logger and 
excalibur.logger separate (at least the LoggerManager
and the its implementations)?
Could they be united in Avalon5?

>>>Keep in mind that COP (i.e. Avalon environment) has a different
>>>set of constraints than traditional OOP.  Basically, COP forces
>>>you to operate within a certain subset of OOP which simplifies
>>>a number of design decisions you have to make.  It also lends
>>>the benefit of VLC (Very Low Coupling) between implementations
>>>of components.
>>yes - and I appreciate them.   but if we want the Avalon
>>framework and
>>logger to
>>be adopted more widely - we also need to consider that COP is not the
>>only way
>>or the dominant way.
>>The point I'm trying to make is if and how the two can be reconciled .
>In a future version of Avalon, it is something to look at.
>The risks of a rogue component successfully cracking a container's
>security through logging is minimal.
what if a static access method was added to LoggerManager 
implementations to get a singleton instance?
Say, if one wanted to use Log4J via the Avalon Logger framework - 
without any autodiscovery - would would simply write
import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.excalibur.logger.Log4JLoggerManager;
public class MyClass {

    private static Logger logger = 


Effectively, that would allow OOP-style development with Avalon and 
"prepare the ground" for COP if and when they decided to?
One might introduce some mechanism to disable the singleton access when 
the component was deployed in  a container.

BTW, I've noticed that the framework.logger.Log4JLogger still used log4j 
Since 1.2.x has deprecated Category and Priority and these are going to 
disappear in the next few months
I've updated the Log4JLogger to use the non deprecated classes/methods.
Being a wrapper class it should have any effect elsewhere nor should it 
matter for backward compatibility.  
Also I've noticed that other parts of Avalon (eg. Excalibur) use log4j 
1.2 so it would better to be consistency.
A patch is attached.  And lib has to updated accordingly to use any 


View raw message