Noel J. Bergman wrote:
ugh. With a logging tool, you want as little exceptions as possible, as "not completely correct" behaviour of the logging toolkit in non-critical areas like this is ok. So while this makes sense in a swing world, I think it doesn't in logkit. Also, I think unicast instead of multicast in a logging tool makes sense if you don't need multicast: less overhead.public synchronized void add<T>Listener(<T>Listener listener) throws java.util.TooManyListenersException;I think maybe the method instead should be set<T>Listener then so the contract is clear.Please see: http://java.sun.com/products/javabeans/docs/beans.101.pdf section 6.5.2. The contract is clear and specified:public void add <ListenerType>( <ListenerType> listener) throws java.util.TooManyListenersException; The reason for this is documented: "Note that the unicast pattern is a special case of the multicast pattern and as such allows migration of a unicast event source to a multicast event source, without breaking existing client code." Unicast methods are somewhat discouraged.
OTOH, allowing migration to a multicast source without breaking existing code does present a convincing argument for not changing methodname.
so we're back at square one.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]