> From: Mauro Talevi [mailto:[EMAIL PROTECTED]] > > 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 ....
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. > 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. 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. > 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. You will find that in just about all cases, this is the most manageable solutions. Esp. when there is custom classloader stuff that needs to happen. > - 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 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. > - 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. We even have one of those. > 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. 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. > 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. > 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? We tried in the past.... > 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. 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. > 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. > 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. They strongly oppose it because they want to be the standard. They also don't want any dependency on Avalon whatsoever. > >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? 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. 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
