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 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]
>>
>>
>>
>>
>>This e-mail, including any attachments, is a confidential business
>>communication, and may contain information that is confidential,
>>proprietary and/or privileged. This e-mail is intended only for the
>>individual(s) to whom it is addressed, and may not be saved, copied,
>>printed, disclosed or used by anyone else. If you are not the(an)
>>intended recipient, please immediately delete this e-mail from your
>>computer system and notify the sender. Thank you.
>>
>>
>>---------------------------------------------------------------------
>>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]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
