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]
