http://incubator.apache.org/projects/altrmi/monitors.html
I've reworked AltRMI to use a Logger impl agnostic design. Basically the idea is that by default AltRMI logs to the command-line using system.out unless an individual instance (our important distinction) of a server or a client has had setMonitor(..) called. I've coded adapters for Log4J, A-F Logging, Commons-Logging, Java 1.4 Logging. I've also coded a NullLogger. Anyway, the user of the reusable bean/comp has max flexibility WRT logging (or not). They are not dependent at runtime on *any* logging framework if they don't want to be.
Does this concept have legs? My feeling is that application coders choose a logging mechanism, but bean/comp coders should not do so. My proof for the this is born from TDD. Why log? - You don't test the textual output to a logger? If you do it is pointless testing it as no deterministic use of that textual dump is ever coded. for a bean/comp user. Much better a monitor.
It certainly has flaws. Namely, you should wait a while until you finalise your monitor interface. And suffer the impact of change thru revisions.
Does anyone want to help me crisp this up? 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).
Regards,
- 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]
