avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: No Logging (TM)
Date Thu, 03 Apr 2003 09:41:37 GMT
Paul Hammant wrote:
> I've reworked AltRMI to use a Logger impl agnostic design.  Basically 
> the idea is that by default AltRMI logs to the command-line using 
> system.out unless an individual instance (our important distinction) of 
> a server or a client has had setMonitor(..) called.  I've coded adapters 
> for Log4J, A-F Logging, Commons-Logging, Java 1.4 Logging.  I've also 
> coded a NullLogger.  Anyway, the user of the reusable bean/comp has max 
> flexibility WRT logging (or not). They are not dependent at runtime on 
> *any* logging framework if they don't want to be.

why is

final NullLogger implements Logger
	private NullLogger m_instance = null;
	public NullLogger getInstance()
		if( m_instance != null )
			return m_instance;
		m_instance = new NullLogger();
		return m_instance;
	private NullLogger() {}

	public void debug( final String msg ) {}

	// ... rest of the empty impl

// somewhere
MyBean b = new Bean();
Util.setLogger( b, NullLogger.getInstance() );

bad? This kind of Logger approach is a kind of monitoring setup too, but 
a very specific one. Poor man's AOP. You can easily take that further:

abstract class MyAbstractBean // implements LogEnabled in the A-F case
	protected Logger m_logger = NullLogger.getInstance();
	setLogger( Logger logger )
		m_logger = logger;

which permits

class MyBean extends AbstractBean
     public close() throws Exception
         m_logger().error( Class clazz, String s, IOException e );

// somewhere
MyBean b = new Bean();
b.close(); // ie, remove IoC and the requirement to call setLogger()

Using something like

public interface ServerMonitor {
    void closeError(Class clazz, String s, IOException e);
    void badConnection(Class clazz, String s, BadConnectionException bce);
    void classNotFound(Class clazz, ClassNotFoundException e);
    void unexpectedException(Class clazz, String s, Exception e);
    void stopServerError(Class clazz, String s, Exception e);

seems like opting for a more general monitoring/messaging system to 
handle logging and general application setup, yet defining only some 
specific events. Everytime you define a new event you have to change 
ServerMonitor, in fact leading to much more coupling everywhere.

This ServerMonitor is all but completely nonportable, meaning 
ServerMonitor impls are also nonportable. Is every app layer/component 
(like altrmi) to have a different kind of Monitor, along with 
implementations? If not, what do you envision your generalized monitor 
to look like?

If you want to loose the specification that the Logger interface is just 
about logging, I think it makes sense in that case to go all the way 
with that approach:

public interface Event { /* ... */ }
public interface Monitor { handle( Event e ); }

// and then something like

public class CloseErrorEvent implements Event { /* ... */ }
public class BadConnectionEvent implements Event { /* ... */ }
public class ClassNotFoundEvent implements Event { /* ... */ }
public class UnexpectedExceptionEvent implements Event { /* ... */ }
public class stopServerErrorEvent implements Event { /* ... */ }

// but rather just

public class ExceptionEvent implements Event
  /* ... */
  Exception getException();

Or use true AOP or interceptor chaining, or a combination of those. 
Going back to specific method calls feels like a step back, not forward.

> My feeling is that application coders 
> choose a logging mechanism, but bean/comp coders should not do so.

+1. This is exactly what A-F framework and commons logging are ment to 
address, no?

> I'd hope that a decent 
> document can be created and we can approach other groups to help with a 
> rollback of static logging (or hard wired logging impls).

Advocacy of instance-based programming is good (way down on the TODO 
list: write "static considered harmful" paper), but I really don't 
understand what you're trying to accomplish with this. AFAICS, the 
problem is already solved and we just need more people to start using 
the solution.



To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message