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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
