But what is wanted here is not logging, but a way of notifying the+1000.
application that something is happening inside the server.
Logging happens to be choice after that.
That's what I said !? ;-)If that notification then translates to log output being produced then that is not the concern of the AltRMI code.
True true. The Avalon-adapter block can automagically connect up A-F logging in the usual LogEnabled way. //TODOWhile 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 system.
:-)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.
a) a long list of if...elseif...else+1
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.
+1My feeling is that application coders+1. This is exactly what A-F framework and commons logging are ment to
choose a logging mechanism, but bean/comp coders should not do so.
address, no?
I think the issue here is: Is monitoring a server always equivalent to logging? In this case, I think not.
Kewl stuff - Leo and I agree on something :-)
- 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]
