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.
I'm happy with that. To me it is no differnt from any other part of the bean/comp's API.
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?
I have no vision of a generalised monitor.
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:
I do.
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 { /* ... */ }
Too many new classes. Bloat. With the ServerMonitor as I prescribed it, there is only one interface, and a minimum of one default impl.
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.
Good for a logging view. To me this is part of the API now.
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?
Yes, but bean/comp coders *are* choosing a logging framework.. Commons is littered with it. A-E is not.
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.
Wrong, previous approaches have tried to advocate A-F logging or A-L logging over others.
This approach is about 'no logging'. Deterministic programming based on erstwhile logged events is now possible. Logging at bean/comp level is a fallacy :-)
Another wisdom of soloman solution.
- Paul
-- http://www.thoughtworks.com : The art of heavy lifting. Home for many Agile practicing Open Source activists...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
