Paul,
OK then, let us go with PropertyChangeEvent. We can change later if we discover the need.
At 10:01 AM 9/6/2003 +1000, Paul Smith wrote:
[MS Exchange web client sucks, so can't reply with comments in line, sorry]
PropertyChangeEvent is definately generic, which is why it is so powerful. I think having additional listener style interfaces for certain events is still a good idea as weel, and shouldn't be too burdensome.
I see the PropertyChange stuff bound to individual entities (Receivers, Appenders, Loggers), and the more broader events like you mentioned availabled via LogManager or the associated "root" of the related object hierarchy (does that make sense?).
That way for those interested in the finer grained property change events can bind away to the individual objects, but those requiring coarse grained events can do that too.
Both have usefulness.
I can volunteer to do Plugins/Receivers event structures (property change and the coarses grained stuff).
cheers,
Paul
-----Original Message----- From: Ceki Gülcü To: Log4J Developers List Sent: 9/6/03 5:33 AM Subject: Re: Plugins & PropertyChangeListener
Paul,
A PropertyChangeListener receives PropertyChangeEvent objects which are quite generic.
It seems to me that if the type of events that are going to be generated is unknown, then PropertyChangeListener/PropertyChangeEvent might be the right way.
If however, the type of events are known in advance and their number small (number of types), then writing a specific interface (see o.a.l.spi.LoggerEventListener, HierarchyEventListener) might be most appropriate.
Do you know the types of events you are interested in for the plugins?
At 03:41 PM 9/5/2003 +1000, Paul Smith wrote: >Could we extend Plugins to support the concept of >PropertyChangeListeners (java.bean package stuff)? > >PropertyChangeListener and associated classes are a great way of binding >objects together and being notified when certain properties change. >This allows for a very nicely decoupled design, particular in GUI's. > >What I would propose to do is modify PluginSkeleton to add the following >methods: > >public void addPropertyChangeListener(PropertyChangeListener l); >public void removePropertyChangeListener(PropertyChangeListener l); > >For each setter property in PluginSkeleton and it's children, modify the >method to fire a PropertyChangeEvent. Listeners can then modify >themselves based on the old/new value accordingly. > >We can use the PropertyChangeSupport class to do most of the heavy >lifting. Since Swing uses these classes extensively, they have been >optimized to ensure that if no-one is listening, as little CPU/memory as >possible is wasted. > >Does anyone have any objects, or comments? > >cheers, > >Paul Smith > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
See you in November at ApacheCon US 2003 in Las Vegas. http://apachecon.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp See you in November at ApacheCon US 2003 in Las Vegas.
http://apachecon.com/--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
