RE: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration

> From: Mauro Talevi [mailto:[email protected]]
> 
> Berin,
> 
> 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?

You dont necessarily need that part.  It was created primarily
to make configuring LogKit easier.  ECM, Fortress, and (I believe)
Phoenix use Excalibur Logging--but Merlin does not.  It isn't
necessary, but it is useful.


> >>>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.
> >
> >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?

I really don't like that notion at all.  Not all containers
in a heirarchy of containers should share the same LoggerManager.
I have found that the Singleton pattern is *far* too overused,
and when it is used inappropriately it causes more problems than
solutions.

> 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 = 
> Log4JLoggerManager.getInstance().getDefaultLogger();
> 
> }

If you wanted your component to get a logger, all you have to
do is implement the LogEnabled interface.  It's not hard at all.

You are also defeating the logger neutral stance that components
MUST have.  You can develop a component with a container using
the Log4JLoggerManager, but you cannot guarantee that it will never
be run on a container using the LogKitLoggerManager.

Singletons only serve to cause problems in this manner--a component
must be logging kit neutral because the container controls which
logging toolkit is used and which isn't.

> 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.

It's really more work than its worth.  With proper IoC, you can
get the same effect as COP, while still using OOP.  You can't
do it in a way that won't cause issues with the software later.

It is very difficult to get poorly written OOP to become a decoupled
component.


> BTW, I've noticed that the framework.logger.Log4JLogger still 
> used log4j 
> 1.1.x.
> 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.

Yes, we really need to do that.

> 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 
> log4j-1.2.x.jar


Thanks.