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.
cheers!
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
