Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)

[Leo Simons]

Paul Hammant wrote:

The class is fine, but let us not market it as Commons logging in Avalon-Framework.

agreed. My idea was to not market it at all :D

 This is what /they/ want :-

 public class Foo {
     private static final Log logger = LogFactory.getLog(Foo.class);
    // other methods          static {
         logger.info("yee haaa");
     }
 }

I thought so too at first, but there is no "they". Some people want to do things this way. There are also people looking to use commons-logging in a non-static setup, and that is indeed possible. It is this which I want to accomodate (and encourage). The use of a static Log is possible already without the CommonsLogger class.

We have not engineered a solution,

true.

Any kind of 'circumvent-the-static' 'solution' must grasp total control over the classloading to replace LogFactory with a no-op solution, and what you have then is loss of log information, so it is real ugly. Or the container must go further provide a custom LogFactory implementation which does bytecode hacking of the hosted components in order to figure out where the log call came from so it can determine where it should go. Quite complex and a source for bugs, so I'm against it (well, not against it, but I certainly won't be writing it).

just a delegate that is instance orientated :-

public Foo implements LogEnabled {
Logger logger;
pubic void enableLogging(Logger logger) {
this.logger = logger;
}
static {
// whoops can't do logging here.
}
}

exactly.

So -1 .. it adds nothing that we did not have already.

I agree with everything you say but the conclusion you draw. The code snippet above is exactly the functionality people are asking for, and it does add something.

Two examples:

1) a custom in-house legacy logging tool that is wrapped with a class that implements commons-logging Log. For example, you might have an existing C application that does your logging, with a JNI interface which implements Log. The CommonsLogger class allows you to easily use that logging tool from within an avalon component.

2) an existing application or component uses commons-logging in a non-static way and you want to migrate to (or wrap as avalon components). A concrete code example which wraps commons-digester:

interface Digester
{
parse( File file ) throws IOException, SAXException;
}

class DigesterWrapper extends AbstractLogEnabled
implements Digester, Parameterizable
{
Digester m_digester;
Parameters m_parameters;

DigesterWrapper()
{
}

parameterize( Parameters parameters )
{
m_parameters = parameters;
}

initialize() throws Exception
{
if( ! m_logger instanceof CommonsLogger )
throw new IllegalStateException(
"doing lazy migration...CommonsLogger required!" );

m_digester = new Digester();
m_digester.setLogger( (CommonsLogger)m_logger );

String[] names = parameters.getNames();
for( int i = 0; i < names.length; i++ )
{
m_digester.setProperty( name, getParameter( names[i] ) );
}
}

parse( File file ) throws IOException, SAXException
{
return m_digester.parse( file );
}
}

Note that the Digester class doesn't contain a static {} block and the Digester constructor does nothing. So what you have here is a fully functional, fully IoC avalon component. Of course, there's lots of alternatives to accomplish the same thing, but all of them will introduce either additional dependencies within commons-digester or an additional dependency (and additional work) in the digester wrapper, and result in less clean code in the digester wrapper.

convinced yet?

cheers,

- Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]