avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <P...@ThoughtWorks.net>
Subject Re: No Logging (TM)
Date Thu, 03 Apr 2003 11:00:30 GMT

> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message