Berin, 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 :-(
There is in general quite a strong resistance in learning/adopting new frameworks if theIn 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.
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.
true
Keep in mind that COP (i.e. Avalon environment) has a differentyes - and I appreciate them. but if we want the Avalon framework and logger to
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.
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:-)
The issues raised by Ceki are very interesting and quite relevant to Avalon too,2. IoC is not a sacred cow and we can fall short of it if needed.In the logging environment that is a possibility due to the lower
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.
risk of what happens in the logging environment. But the autodiscovery
is a serious sticking point.
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).
Commons-logging is not as used as log4j - if Avalon could draw in the log4j usersThey strongly oppose it because they want to be the standard. They also don't want any dependency on Avalon whatsoever.
it could really explode in users.
I meant that Log4J doesn't require (like Commons Logging) for the loggable componentLog4J 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.
to be LogEnabled.
He enumerated a number of points of contention with Commons' autodiscovery mechanisms. The enclosed link describes all the problems. http://qos.ch/logging/thinkAgain.html
thanks! very interesting indeed. Cheers, Mauro -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
