Berin Loritsch wrote:
It seems to me that Commons Logging and Avalon Logger share a lot of commonality, in theFrom: 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?
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.
In the general attitude of Avalon scism riunification, wouldn't it be best to try and understand whatAnyway, 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.
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.
It's not quite clear to me how much Log4J differs from Commons Logging. Could you explain or point to the link?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.
Cheers, Mauro
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
