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

Berin Loritsch wrote:

>>From: Nicola Ken Barozzi [mailto:[email protected]]
>>
>>Jakarta Commons is recreating, piece by piece, various parts 
>>of Avalon 
>>and more than once I've heard strong suggestions that all 
>>should follow 
>>that "standard".
>>
>>How should we deal with these issues?
>>
>>Would it make sense to use Commons Logging interfaces and work with 
>>Commons configuration on Avalon 5?
>>
>>    
>>
It seems to me that Commons Logging and Avalon Logger share a lot of 
commonality, in the
sense that both are facades that delegate to underlying loggers - Log4J, 
LogKit, JDK14 ....

Of course, Logger came before Logging but at the moment is rapidly 
gaining in popularity
because it is probably seen as something more lightweight that does not 
require the full avalon framework.

The main difference I see in the two is that:

- Logger enforces the IoC and has essentially a top-down approach,
you specify the logging configuration in the environment.xml  and it is 
used consistently throughout the app, provided
you either extend AbstractLogEnabled or you LogEnable a component - but 
this component has to implement the
LogEnabled interface.
 
- Logging on the other hand adopts an "autodiscovery" bottom-up 
approach, in that the logger is found via a
factory based on properties or system properties found in the classpath.
This has the advantage that is makes much easier to "get up and running" 
- it even provides a very simple logger implementation -
which can then be replaced by one more substantial logger.  
Also - more importantly - Logging can be used to develop components 
independently of any framework, eg components
that implements some specific business logic that you may or may not 
want to embed or offer in this or that framework.

The problem I've come across is this:  you develop an API which is 
self-consistent and runnable stand-alone,
with different interfaces, command-line, servlet, rich-client etc.   And 
you use Logging in this API because of the reasons outlined above.
Then you realise the power of Avalon and want to offer the functionality 
via Avalon - eg a Phoenix Sar.

It would be extremely useful to have to ability to keep the log 
interface the same and hook into the Avalon Logger.  

Now that Avalon has become a TLP it would be a great opportunity to talk 
to the Commons Logging people to
draw up a "common" API that would satisfy the needs of more than one 
type of application.  In the end that's the purpose of a facade, isn't?

Here again different approaches depending on how strong one feels about 
preserving the IoC.
A couple of ideas that have been thrown up in the air when I posed the 
issue of Logging-Logger compatibility
in Phoenix:

1. IoC is the foremost priority and we should endevour to not have not 
have the "autodiscovery".
To embed components "logged" with Commons Logging one would have to 
introduce a
CommonsLogEnabled interface to be added to the framework that would
enable Avalon container to recognize and have adapters to the Avalon 
Loggers.

2. IoC is not a sacred cow and we can fall short of it if needed.
Eg one might keep the Logger that is created when the Phoenix Sar is 
deployed in a thread local variable
and have the Commons Logging factory retrieve the logger from it.

>>Anyway, I will propose again to our list that we use the Logger
>>interface somehow in the new Avalon 5, or try somehow to 
>>reunite the scism.
>>
>>Remember though that the fact that commons strongly opposes anything
>>that has even a remote hint about avalon framework really 
>>doesn't help.
>>
In the general attitude of Avalon scism riunification, wouldn't it be 
best to try and understand what
the commons people strongly oppose of the Logger framework?  
Again - to me they seem remarkably similar in spirit.  From a design 
point of view you would say that
they are inspired by the same pattern.

>Ceki Gulcu (sp?) the author of Log4J has raised a number of issues
>regarding Commons Logging, and most of the problems come with the
>auto-discovery mechanism.  The Avalon implementation does not suffer
>from these problems.
>
>I asked Ceki what he felt about Avalon's logging abstraction, and
>I explained to him what the architecture was.  He didn't have the
>time to take a look, but based on my description he was happy that
>it did not have all the installation and runtime problems
>(architecturally) that Commons Logging does.
>
>Furthermore, Commons Logging does not allow for container managed
>logging targets because everything is statically accessible--and
>circumvents our carefully planned IoC architecture.
>
>Perhaps we should work with Ceki's document (the link escapes me)
>and reference it when we write our FAQ entry.
>
It's not quite clear to me how much Log4J differs from Commons Logging.  
Could you explain or point to the link?

Cheers, Mauro