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 Thu, 12 Dec 2002 20:05:44 GMT

Berin Loritsch wrote:

>That is about the extent of their commonality.  I tried to get them
>to support an interface that is IoC friendly, but they kept wanting
>to do it the other way--in effect working against the way Avalon
>does things 
uhm - not exactly what one would call a "common" approach :-(

>In reality, the full Avalon framework is lighter-weight.  The Commons
>Logging implementation is like using a sledge hammer when a ball
>peen hammer would be called for.
There is in general quite a strong resistance in learning/adopting new 
frameworks if the
advantages are not clear and cut.
Also Avalon Logger is "buried" in the framework and the perception that 
people get
of Avalon is that it is a "heavy" framework - certainly heavier than the 
Commons Logging and/or Log4j.
Perhaps because they associate it the apps built on top of it.

>It is much easier to get *simple* programs up and running.  The
>stark reality of autodiscovery is that it is less than perfect.
>In environments where you cannot control the classloader or
>alter system properties, you cannot configure and set up your
>logging system the way you want.

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

>>It would be extremely useful to have to ability to keep the log 
>>interface the same and hook into the Avalon Logger.  
>It would.  It seems that any attempts with the Commons Logging
>crew to implement a braindead solution that can be incorporated
>into Avalon failed.  Instead you have all the problems of autodiscovery
>without any of the benefit of the controlled environment that
>COP affords.
final words?  no room for negotiation?

>In the end, if we could have one interface extend the other, we could
>have it work.  To date, neither project has been willing to depend
>on the other.
I take this is unlikely to change:-)

>>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.
>In the logging environment that is a possibility due to the lower
>risk of what happens in the logging environment.  But the autodiscovery
>is a serious sticking point.

The issues raised by Ceki are very interesting and quite relevant to 
Avalon too,
especially the dynamic discovery.
Could it be a basis for a discussion on the Avalon5 logging framework?
In my opinion, the issue is if a dynamic discovery mechanism of some 
kind can be implemented
that is compatible with IoC and COP.  
commons-logging is one autodiscovery mechanism - not the only one - and 
I personally found it
appealing because it provided a facade (I had not given too much thought 
about the classloader issues).

>They strongly oppose it because they want to be the standard.
>They also don't want any dependency on Avalon whatsoever.
Commons-logging is not as used as log4j - if Avalon could draw in the 
log4j users
it could really explode in users.

>Log4J is just like LogKit or JDK 1.4.  The major issue is that
>he has received a number of support requests for Log4J because of
>environmental issues introduced by Commons Logging.

I meant that Log4J doesn't require (like Commons Logging) for the 
loggable component
to be LogEnabled.

>He enumerated a number of points of contention with Commons'
>autodiscovery mechanisms.
>The enclosed link describes all the problems.
thanks!  very interesting indeed.

Cheers, Mauro

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

View raw message