[sip-comm-dev] PropertyChangeListener/Event


#1

Guys,

I need PropertyChangeListener/Event. Since I found such classes in the
.configuration.event package and they didn't seem at all bound to the
configuration, I decided to move them to .util in order to make them
available to more consumers. Then it turned out the code already uses
the respective classes of java.beans.*. Can we just use one of them
and not the other? If I had to choose, I'd probably use the
java.beans.* ones because they're generic enough and they'll spare me
maintenance. But then again I don't really care which one will remain,
just using two seems unnecessarily complicated.

Best regards,
Lubo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey Lubo,

Lubomir Marinov wrote:

Guys,

I need PropertyChangeListener/Event. Since I found such classes in the
.configuration.event package and they didn't seem at all bound to the
configuration

Hmm. Did you notice the possibility to add property change listener in
the configuration service?

http://tinyurl.com/sc-propchangelistener-usage

Or did you meant that the listener seemed more generic than the scope of
the config service which is why you'd like to move it?

I decided to move them to .util in order to make them
available to more consumers. Then it turned out the code already uses
the respective classes of java.beans.*.

Hmm ... not sure I understand. ConfigurationService.java does not import
java.beans. How could it be using it?

Can we just use one of them
and not the other? If I had to choose, I'd probably use the
java.beans.* ones because they're generic enough and they'll spare me
maintenance.

Well as a matter fact the configuration service was one of the very
first classes written in SC so there were a number of provisions that
were made there because "we might need them one day". The reason we have
a property change listener there is because we might need to do more
than straightforward change notification.

Obviously three years of development haven't brought up such use cases
so I am not opposed to falling back to the java.beans class (although we
might one day need .... :slight_smile: )

Cheers
Emil

···

But then again I don't really care which one will remain,
just using two seems unnecessarily complicated.

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil,

Thank you for the timely response!

The ConfigurationService defines its own
.configuration.event.PropertyChangeListener and
.configuration.event.PropertyChangeEvent which are currently
generic/not bound to the ConfigurationService. It and its clients use
them.

Elsewhere in the SIP Communicator code
java.beans.PropertyChangeListener and java.beans.PropertyChangeEvent
are used.

When I wanted to use PropertyChangeListener and PropertyChangeEvent, I
had to decide whether to use of the two or write my own copies.
Because .configuration.event.PropertyChangeListener/Event were generic
and abstractions with the same functionality are available in Eclipse
under the names IPropertyChangeListener and IPropertyChangeEvent, I
thought it wouldn't be a mistake to officially promote
.configuration.event.PropertyChangeListener/Event to generic use and
move them to .util.PropertyChangeListener/Event.

Future specialization of the ConfigurationService and its
property-change notification architecture is still not hindered by the
move described above - data and behavior unforeseen at this time can
still be added through class specialization/extending.

The questions I rather raised were:

- How does a new developer decide which one of the two abstractions
for one and the same functionality decide which one to use?

- Is it necessary to maintain a couple of files which provide
functionality available in the JRE?

- And probably the one of least interest to anyone, is it worth it to
load two abstractions for one and the same functionality at run time,
to distribute a "copy" of functionality available in the JRE?

Best regards,
Lubo

···

On Thu, Nov 20, 2008 at 12:52 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Lubomir Marinov wrote:

Guys,

I need PropertyChangeListener/Event. Since I found such classes in the
.configuration.event package and they didn't seem at all bound to the
configuration

Hmm. Did you notice the possibility to add property change listener in
the configuration service?

http://tinyurl.com/sc-propchangelistener-usage

Or did you meant that the listener seemed more generic than the scope of
the config service which is why you'd like to move it?

I decided to move them to .util in order to make them
available to more consumers. Then it turned out the code already uses
the respective classes of java.beans.*.

Hmm ... not sure I understand. ConfigurationService.java does not import
java.beans. How could it be using it?

Can we just use one of them
and not the other? If I had to choose, I'd probably use the
java.beans.* ones because they're generic enough and they'll spare me
maintenance.

Well as a matter fact the configuration service was one of the very
first classes written in SC so there were a number of provisions that
were made there because "we might need them one day". The reason we have
a property change listener there is because we might need to do more
than straightforward change notification.

Obviously three years of development haven't brought up such use cases
so I am not opposed to falling back to the java.beans class (although we
might one day need .... :slight_smile: )

Cheers
Emil

But then again I don't really care which one will remain,
just using two seems unnecessarily complicated.

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Lubo,

Lubomir Marinov wrote:

- How does a new developer decide which one of the two abstractions
for one and the same functionality decide which one to use?

Basically the idea was to use the one in the configuration service when
you need events that originate there and use whatever you want otherwise.

- Is it necessary to maintain a couple of files which provide
functionality available in the JRE?

Of course not. But then again, I don't think anyone intended using our
configuration PropertyChangeListener as a generic tool for handling
property change events in SIP Communicator. It was only meant for use in
the configuration service.

Cheers
Emil

···

Best regards,
Lubo

On Thu, Nov 20, 2008 at 12:52 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Lubomir Marinov wrote:

Guys,

I need PropertyChangeListener/Event. Since I found such classes in the
.configuration.event package and they didn't seem at all bound to the
configuration

Hmm. Did you notice the possibility to add property change listener in
the configuration service?

http://tinyurl.com/sc-propchangelistener-usage

Or did you meant that the listener seemed more generic than the scope of
the config service which is why you'd like to move it?

I decided to move them to .util in order to make them
available to more consumers. Then it turned out the code already uses
the respective classes of java.beans.*.

Hmm ... not sure I understand. ConfigurationService.java does not import
java.beans. How could it be using it?

Can we just use one of them
and not the other? If I had to choose, I'd probably use the
java.beans.* ones because they're generic enough and they'll spare me
maintenance.

Well as a matter fact the configuration service was one of the very
first classes written in SC so there were a number of provisions that
were made there because "we might need them one day". The reason we have
a property change listener there is because we might need to do more
than straightforward change notification.

Obviously three years of development haven't brought up such use cases
so I am not opposed to falling back to the java.beans class (although we
might one day need .... :slight_smile: )

Cheers
Emil

But then again I don't really care which one will remain,
just using two seems unnecessarily complicated.

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net