RE: Plugins & PropertyChangeListener
If client code wishes to only be notified of a particular property, they
could eventually do something like:
Receiver receiver = ;
receiver.addPropertyChangeListener("threshold", new
PropertyChangeListener() {
public void propertyChanged(PropertyChangeEvent e) {
// I can guarantee that this anonymous class will only get called when
the setThreshold method on the receiver is called.
}
});
That way you can register for all property changes, or just the
properties you are interested in.
cheers,
Paul Smith
On Tue, 2003-09-09 at 01:39, Shapira, Yoav wrote:
> Howdy,
> It's if on the source class (if event.getSource() instanceof XXX) and then on the
> property name. I think the best example is
> org.apache.catalina.mbeans.ServerLifecycleListener, which you can see here:
> http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
>
> To be complete, I'll cover how the events are fired, but you can skip this part if
> you don't care ;)
>
> The firing of events is set up like this, for a class named SomeClass which has
> properties whose change should fire change events. I've removed all but the
> relevant parts. See pretty much any class in org.apache.catalina.core for
> reference, starting with org.apache.catalina.core.ContainerBase.
>
> // SomeClass.java
> import java.beans.PropertyChangeListener;
> import java.beans.PropertyChangeSupport;
> ...
>
> public class SomeClass {
> /**
>* The property change support for this class.
>*/
> protected PropertyChangeSupport support = new PropertyChangeSupport(this);
>
> ...
>
> /**
>* Add a property change listener to this component.
>*
>* @param listener The listener to add
>*/
> public void addPropertyChangeListener(PropertyChangeListener listener) {
> support.addPropertyChangeListener(listener);
> }
>
> ...
>
> /**
>* Set the debugging detail level for this component.
>*
>* @param debug The new debugging detail level
>*/
> public void setDebug(int debug) {
> int oldDebug = this.debug;
> this.debug = debug;
> support.firePropertyChange("debug", new Integer(oldDebug),
>new Integer(this.debug));
>
> }
> }
>
> setDebug is an example of a property chose change we broadcast. Listeners can do
> whatever they want with it.
>
> Yoav Shapira
> Millennium ChemInformatics
>
>
> >-Original Message-
> >From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> >Sent: Monday, September 08, 2003 10:32 AM
> >To: Log4J Developers List; Log4J Developers List
> >Subject: RE: Plugins & PropertyChangeListener
> >
> >
> >Hi Yoav,
> >
> >What is the coding pattern you use within PropertyChangeListener to
> >process the various types of events?
> >
> >Is it by 'if' statements on the source of the PropertyChangeEvent or the
> >property name?
> >
> >Do you have a code snippet somewhere in your hat?
> >
> >At 09:00 AM 9/8/2003 -0400, Shapira, Yoav wrote:
> >
> >>Howdy,
> >>FYI, for Tomcat the criterion of "their number is small" (the number of
> >>property change events) is false, i.e. the number is huge, so we chose to
> >>stick with the generic PropertyChangeEvent, and it's working very
> >>well. So +1 on your choice, I think it's good.
> >>
> >>Yoav Shapira
> >>Millennium ChemInformatics
> >>
> >>
> >> >-Original Message-
> >> >From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> >> >Sent: Monday, September 08, 2003 8:05 AM
> >> >To: Log4J Developers List
> >> >Subject: RE: Plugins & PropertyChangeListener
> >> >
> >> >
> >> >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 (Receiver
RE: Plugins & PropertyChangeListener
I think we should definately start with PropertyChange stuff, and then build on top of it the coarse-grained events that can't be done by PropertyChange. The events I see that can't be done, and it's not exhaustive, are: * New Appender/Receiver initialized/started (LogManager/PluginRepository responsible here) * Options Activated - this could be interesting, it is a sibling of PropertyChange. I see indiviual setter operations exposing PropertyChange, but the OptionHandler stuff broadcasting when those changed options become effective. Some client code can then call back to find out what the current options are, but some clients might be interested in the actual change itself. For example, an Editor GUI would want to know when the property has changed for display purposes, even if it has not been activated yet. There's probably others. cheers, Paul Smith On Mon, 2003-09-08 at 23:00, Shapira, Yoav wrote: > Howdy, > FYI, for Tomcat the criterion of "their number is small" (the number of property > change events) is false, i.e. the number is huge, so we chose to stick with the > generic PropertyChangeEvent, and it's working very well. So +1 on your choice, I > think it's good. > > Yoav Shapira > Millennium ChemInformatics > > > >-Original Message- > >From: Ceki Gülcü [mailto:[EMAIL PROTECTED] > >Sent: Monday, September 08, 2003 8:05 AM > >To: Log4J Developers List > >Subject: RE: Plugins & PropertyChangeListener > > > > > >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. Liste
RE: Plugins & PropertyChangeListener
Howdy,
It's if on the source class (if event.getSource() instanceof XXX) and then on the
property name. I think the best example is
org.apache.catalina.mbeans.ServerLifecycleListener, which you can see here:
http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
To be complete, I'll cover how the events are fired, but you can skip this part if you
don't care ;)
The firing of events is set up like this, for a class named SomeClass which has
properties whose change should fire change events. I've removed all but the relevant
parts. See pretty much any class in org.apache.catalina.core for reference, starting
with org.apache.catalina.core.ContainerBase.
// SomeClass.java
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
...
public class SomeClass {
/**
* The property change support for this class.
*/
protected PropertyChangeSupport support = new PropertyChangeSupport(this);
...
/**
* Add a property change listener to this component.
*
* @param listener The listener to add
*/
public void addPropertyChangeListener(PropertyChangeListener listener) {
support.addPropertyChangeListener(listener);
}
...
/**
* Set the debugging detail level for this component.
*
* @param debug The new debugging detail level
*/
public void setDebug(int debug) {
int oldDebug = this.debug;
this.debug = debug;
support.firePropertyChange("debug", new Integer(oldDebug),
new Integer(this.debug));
}
}
setDebug is an example of a property chose change we broadcast. Listeners can do
whatever they want with it.
Yoav Shapira
Millennium ChemInformatics
>-Original Message-
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
>Sent: Monday, September 08, 2003 10:32 AM
>To: Log4J Developers List; Log4J Developers List
>Subject: RE: Plugins & PropertyChangeListener
>
>
>Hi Yoav,
>
>What is the coding pattern you use within PropertyChangeListener to
>process the various types of events?
>
>Is it by 'if' statements on the source of the PropertyChangeEvent or the
>property name?
>
>Do you have a code snippet somewhere in your hat?
>
>At 09:00 AM 9/8/2003 -0400, Shapira, Yoav wrote:
>
>>Howdy,
>>FYI, for Tomcat the criterion of "their number is small" (the number of
>>property change events) is false, i.e. the number is huge, so we chose to
>>stick with the generic PropertyChangeEvent, and it's working very
>>well. So +1 on your choice, I think it's good.
>>
>>Yoav Shapira
>>Millennium ChemInformatics
>>
>>
>> >-Original Message-
>> >From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
>> >Sent: Monday, September 08, 2003 8:05 AM
>> >To: Log4J Developers List
>> >Subject: RE: Plugins & PropertyChangeListener
>> >
>> >
>> >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 P
RE: Plugins & PropertyChangeListener
Hi Yoav, What is the coding pattern you use within PropertyChangeListener to process the various types of events? Is it by 'if' statements on the source of the PropertyChangeEvent or the property name? Do you have a code snippet somewhere in your hat? At 09:00 AM 9/8/2003 -0400, Shapira, Yoav wrote: Howdy, FYI, for Tomcat the criterion of "their number is small" (the number of property change events) is false, i.e. the number is huge, so we chose to stick with the generic PropertyChangeEvent, and it's working very well. So +1 on your choice, I think it's good. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Ceki Gülcü [mailto:[EMAIL PROTECTED] >Sent: Monday, September 08, 2003 8:05 AM >To: Log4J Developers List >Subject: RE: Plugins & PropertyChangeListener > > >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/ >&
RE: Plugins & PropertyChangeListener
Howdy, FYI, for Tomcat the criterion of "their number is small" (the number of property change events) is false, i.e. the number is huge, so we chose to stick with the generic PropertyChangeEvent, and it's working very well. So +1 on your choice, I think it's good. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Ceki Gülcü [mailto:[EMAIL PROTECTED] >Sent: Monday, September 08, 2003 8:05 AM >To: Log4J Developers List >Subject: RE: Plugins & PropertyChangeListener > > >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 unsubscr
RE: Plugins & PropertyChangeListener
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]
RE: Plugins & PropertyChangeListener
[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]
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]
RE: Plugins & PropertyChangeListener
I'm all for extending Plugins/Receivers etc to match whatever change listeners we choose to implement for v1.3. -Mark > -Original Message- > From: Ceki Gülcü [mailto:[EMAIL PROTECTED] > Sent: Friday, September 05, 2003 6:49 AM > To: Log4J Developers List > Subject: Re: Plugins & PropertyChangeListener > > > > Hello Paul, > > Sending notifications on change is definitely a feature to be > added for > 1.3. Actually, this feature is not only required for plugins > but for most > components (logger repositories, loggers, appenders, layouts). > > We already have change listeners. Let me look at how > PropertyChangeListeners differ and get back to you. > > 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]
Re: Plugins & PropertyChangeListener
Hello Paul, Sending notifications on change is definitely a feature to be added for 1.3. Actually, this feature is not only required for plugins but for most components (logger repositories, loggers, appenders, layouts). We already have change listeners. Let me look at how PropertyChangeListeners differ and get back to you. 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]
