Leo:
I noticed the commit and am very pleased to see it in place.
Cheers, Steve.
Leo Simons wrote:
Hi peeps,
I thought I'd draw some more attention to this as it seems like this
might be a contentious issue and it should not be in the way of a
4.1.4 release (ie if this turns out to be contentious I'll remove the
class again for now).
I just wrote and committed a single class,
org.apache.avalon.framework.logger.CommonsLogger, which implements
Logger by (trivially) wrapping around commons-logging. I also added in
proper conditionals in the build so that things build properly if
commons-logging is not available.
Like all code, it is subject to a lazy consensus vote. If you don't
want CommonsLogger in 4.1.4 (despite the sound arguments below :D),
please say so ASAP so any discussion isn't in the way of a 4.1.4
release. I don't want to steamroll this in.
cheers,
- Leo
Leo Simons wrote:
Paul Hammant wrote:
Leo,
public final class CommonsLogger
implements Logger, Log
I'm not sure this adds anything to A-F.
I thought about this for a long time before doing anything, and I'm
relatively sure that it does now :D. There's a lot of people using
commons-logging, and quite a few people have requested or suggested
that avalon use or at least enable the use of commons-logging. So it
satisfies a real, existing requirement.
Adding this single class doesn't have any impact on existing avalon
code (or future avalon code) and is fully backwards-compatible. It
adds only minimally to the size of avalon-framework.jar. Maintainance
overhead is also neglegible. It enables future integration of
alternative commons-logging-based logging solutions.
Besides the technical equation, I must admit I have also given
thought to the positive vibes something like this can generate. It
shows there really is no reason to be sceptical about the healthy
relationship between the various projects.
We already had a means of delegation to Commons-Logging.
we do? Where?
Be careful dude as the static and instance worlds of logging are
idealogically opposed.
I wouldn't go that far, but yep, there's definately room for problems
when we mix the two. However, I believe there can be valid reasons to
indeed want to mix the "pure" IoC/COP avalon promotes and the very
commonly used static factory pattern together.
For example, consider an application with lots of tight coupling to
the commons-logging library. If you want to wrap some of its classes
to be avalon components, your life will be much easier if you can do
something like:
class WorkerWrapper extends AbstractLogEnabled {
initialize() throws Exception
{
if( ! m_logger instanceof CommonsLogger )
throw new IllegalStateException(
"doing lazy migration...CommonsLogger required!" );
m_worker = new Worker(); // like commons-digester :D
m_worker.setLogger( (CommonsLogger)m_logger );
}
}
It might be a little 'ugly', but it sure would make using avalon a
little easier in these situations.
Do you think adding in this class can/will lead to actual problems,
besides sacrificing a little "purity"? If so, where, and how?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
