Hi Niclas,

I was talking about the original monitor pattern which is different from yours.  It abstracts all log messages into individual hook methods. For example:

public MyComplexMonitor {

    public void somethingComplexHappened(ComplexStuff stuff) {
        log.warn("something complex happened: " + stuff);
    }

    public void somethingComplexResolved(ComplexStuff stuff) {
        log.info("something complex has been resolved: " + stuff);
    }
}

You'll have to add a method whenever you have to log something additionally.

What you have done is similar to what MX4J guys have done.  It works great, but we'll have to provide some way for user to specify his or her preferred logging framework and... it's commons-logging do.  It's just like forking commons-logging into org.apache.ldap.server.logging package unfortunately if we're going to use dynamic discovery mechanism to find an appropriate logging framework.

Trustin

2005/10/12, Niclas Hedhman < niclas@hedhman.org>:
If you take it at face value, and don't adopt it to your need, then I agree
that it is over-engineered and an explosion of classes will result.

However, there is a principle in there, which I find good. That you should
isolate your dependencies to a single point if possible. And in case of
logging, that is so simple to do.


public interface OurLogger
{
    // Add methods you need.
    boolean isDebugEnabled();
    void debug( String message );
    void info( String message );
    void warn( String message, Throwable t );
    void error( String message, Throwable t );
}

public class OurLoggerBridgeToLog4J
{
    private Logger m_logger;

    public OurLoggerBridgeToLog4J( Class cls )
    {
        m_logger = Logger.getLogger( cls );
    }

    public boolean isDebugEnabled()
    {
        return m_logger.isDebugEnabled();
    }

    public void debug( String message )
    {
        m_logger.debug( message );
    }

    public void info( String message )
    {
        m_logger.info( message );
    }

    public void warn( String message, Throwable t )
    {
        m_logger.warn( message, t );
    }

    public void error( String message, Throwable t )
    {
        m_logger.error( message, t );
    }
}

public class OurLoggerFactory
{
    public OurLogger getLogger( Class cls )
    {
        // introduce some selector if needed.
        return new OurLoggerBridgeToLog4J( cls );
    }
}

Ok, that took ~10 minutes.
To be more embeddor friendly, introduce a delegation mechanism in the
OurLoggerFactory. Ok, that will take another 10mins.


Considering the reduction of depending on external stuff to a single point
(one class + a factory), the amount of effort required is neglectable.

THAT is what I kept from Hammant's insight. And I am a bit surprised that more
people doesn't see the beauty of this ;o)


Cheers
Niclas



--
what we call human nature is actually human habit
--
http://gleamynode.net/