Paul Hammant wrote, On 02/04/2003 23.56:
Folks,
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.
IIUC this is similar to what I've done, at least conceptually, with the POI stuff, but there I created a POILogger to completely decouple the logging... more on this later.
In fact it seems that the Monitor is conceptually like a Logger. So what you are doing is deciding for a "Logger" interface and saying that a class has to have a setLogger method... no?
So, to simplify the most what about changing the following
public interface ServerMonitor {
void closeError(Class clazz, String s, IOException e);
void badConnection(Class clazz, String s, BadConnectionException bce);
void classNotFound(Class clazz, ClassNotFoundException e);
void unexpectedException(Class clazz, String s, Exception e);
void stopServerError(Class clazz, String s, Exception e);
}To a
public interface Notifier{
void notify(Object[] notifications);
}and
setNotifier(myNotifier);
where the notifications are any object, that the implementation can decide to use or not. Exceptions for example would be typical notifications for example.
This would really decouple.
But... this would mean that we would need a notification.jar that has the above interface. Interfaces are bad for API coupling.
The simplest solution would be to adopt an interface from standard Java API. Example:
addObserver(java.util.Observer o);
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.
What about a standard JDK java.util.Observer?
...
Does anyone want to help me crisp this up?
Mememe! :-)
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).
D E F I N A T E L Y + +
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
