avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: No Logging (TM)
Date Thu, 03 Apr 2003 11:40:13 GMT

> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
> Using something like
> public interface ServerMonitor {
>     void closeError(Class clazz, String s, IOException e);
>     void badConnection(Class clazz, String s, BadConnectionException
>     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.

But what is wanted here is not logging, but a way of notifying the
application that something is happening inside the server.

If that notification then translates to log output being produced
then that is not the concern of the AltRMI code.
While this leads to more coupling, I fail to see this as a bad thing
in this case. If you want logging, then you can wrap this in an
AltRMI block (I think this is what a block is in Phoenix-ese), and
then have minimal coupling between the block and the rest of the

> 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?

Yes. And I prefer this to a hyper-abstract interface, or committing
to a logging framework - AltRMI is notionally below that level.

> If not, what do you envision your generalized monitor to look like?

> 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();
> }

This is similar to Exception handling, where you define a class
for each event and then test on that (although implicitely). This
seems like:

 a) a long list of if...elseif...else

 b) reflection-based dispatch (i.e. for class C, dispatch to method
    "handle" + C.getName ().

I'd prefer to keep that stuff out of AltRMI.

> > 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 think the issue here is: Is monitoring a server always equivalent to 
logging? In this case, I think not. 


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

View raw message