No Logging and Lifecycle

[Leo Sutic <le...@inspireinfrastructure.com>]

http://lsd.student.utwente.nl/jicarilla/StoryOfThe6LifecycleMethods
>>>
The component lived happily for a while, until it heard 
about the no logging strategy on the sixth day, and decided 
that it had better replace its logger with a callback 
mechanism. Since that callback was again more generic 
than its logger, it had to let the latter go. 
<<<

The only problem is that this only pushes the logging one
step further away.

The idea was that you'd have a

    public interface MyCallbackInterface { ... }

that may optionally output log statements:

    public class MyLogger implements MyCallbackInterface { ... }

By transforming the calls into log statements.

So the container still has to figure out that this parameter
is a callback for logging, and I should create a callback-to-logging
adapter and use it.


Random thought: Could we standardize a CallbackLogger as a 
dynamic proxy that creates a log statement based on the method
name and parameters?

    public interface MyCallbackInterface { 
        public void connected (Socket socket);      
        public void disconnected (Socket socket, int bytesTransferred);
    }

Could be output as:

2003-11-25 14:15:01 [my-component-instance] : connected(
Socket[addr=127.0.0.1/127.0.0.1,port=4983,localport=8081] )
2003-11-25 14:15:04 [my-component-instance] : disconnected(
Socket[addr=127.0.0.1/127.0.0.1,port=4983,localport=8081], 128000 )

?

Problems:

 1. How do you select the log level?

 2. Names for parameters. Would be better if one could do

2003-11-25 14:15:04 [my-component-instance] : disconnected( socket =
Socket[addr=127.0.0.1/127.0.0.1,port=4983,localport=8081],
bytesTransferred = 128000 )

Maybe throw even more metadata at it?

/LS


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

Re: No Logging and Lifecycle

[Leo Simons <le...@apache.org>]

Leo Sutic wrote:
> http://lsd.student.utwente.nl/jicarilla/StoryOfThe6LifecycleMethods
> 
> The component lived happily for a while, until it heard 
> about the no logging strategy on the sixth day, and decided 
> that it had better replace its logger with a callback 
> mechanism. Since that callback was again more generic 
> than its logger, it had to let the latter go. 
> <<<
> 
> The only problem is that this only pushes the logging one
> step further away.
> 
<snip/>
> 
>     public interface MyCallbackInterface { 
>         public void connected (Socket socket);      
>         public void disconnected (Socket socket, int bytesTransferred);
>     }
> 
> Could be output as:
> 
> 2003-11-25 14:15:01 [my-component-instance] : connected(
> Socket[addr=127.0.0.1/127.0.0.1,port=4983,localport=8081] )
> 2003-11-25 14:15:04 [my-component-instance] : disconnected(
> Socket[addr=127.0.0.1/127.0.0.1,port=4983,localport=8081], 128000 )
> 
> ?
> 
> Problems:
> 
>  1. How do you select the log level?
> 
>  2. Names for parameters. Would be better if one could do
> 
> 2003-11-25 14:15:04 [my-component-instance] : disconnected( socket =
> Socket[addr=127.0.0.1/127.0.0.1,port=4983,localport=8081],
> bytesTransferred = 128000 )
> 
> Maybe throw even more metadata at it?

add an interceptor around the callback object, have that interceptor do 
the logging. Configure this interceptor with a log category gotten from 
commons-logging, an A-F logger, whatever you want.

The trick is, of course, that you make your component simpler by adding 
a bit of container magic. It remains a tradeoff.

- LSD



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