[sip-comm-dev] Question regarding "PropertyChangeEvent" class


#1

Dear all,

during some tests and looking around in the code :wink: I figured that we
use two "PropertyChangeEvent" classes. One from SC's own net.java.sip.communicator.util
package and one from java.beans package. SC's PropertyChangeEvent has the
same functionality and Methods as the class from java.beans. Somehow
both classes are use "interchangeably" which sometimes leads to confusion
in the code (need to explicitly import class).

Question: is there any specific reason behind this or is it "just due to
history"? If the latter is the case I would propose to clean this up and
stick with the class from java.beans. I could give it a try to do it.

Regards,
Werner

路路路

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


#2

Hello Werner,

Please search through the dev mailing list archive for a brief
discussion/background on the subject - I see in my Gmail archive that
I brought up the same question regarding PropertyChangeEvent/Listener
on 11/20/08 and we exchanged a few e-mails with Emil on the subject on
the dev mailing list.

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


#3

Lubo,

thanks. It seems that it wouldn't do any harm if we clean this
stuff. I'll give it a try and report the outcome.

Regards,
Werner

路路路

Am 07.04.2010 19:26, schrieb Lubomir Marinov:

Hello Werner,

Please search through the dev mailing list archive for a brief
discussion/background on the subject - I see in my Gmail archive that
I brought up the same question regarding PropertyChangeEvent/Listener
on 11/20/08 and we exchanged a few e-mails with Emil on the subject on
the dev mailing list.

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


#4

All,

during the cleanup of the PropertyChangeEvent stuff I found that
SC defined an own exception "PropertyVetoException" that is a subclass
of java's Runtime exception, therefore it is not required to use try/catch
when calling "ConfigurationService.setProperty(...)" methods. In
fact the PropertyVetoException is completely ignored except in one test
case.

The real Java PropertyVetoException (java.beans package) is a subclass
of exception, not of Runtime.

My proposal for the time being: define a new SC specific PropertyVetoException
with a new class name, e.g. PropertyVetoExceptionSc and have it as a
subclass of Runtime as the old SC specific PropertyVetoException. This
name makes it clear that this exception behaves different than the exception
defined in java.beans package.

In the second step we should discuss if an how we use the
real PropertyVetoException instead of just ignoring it and let Felix
report it in case it is thrown.

WDYT?

Regards,
Werner

路路路

Am 07.04.2010 19:40, schrieb Werner Dittmann:

Lubo,

thanks. It seems that it wouldn't do any harm if we clean this
stuff. I'll give it a try and report the outcome.

Regards,
Werner

Am 07.04.2010 19:26, schrieb Lubomir Marinov:

Hello Werner,

Please search through the dev mailing list archive for a brief
discussion/background on the subject - I see in my Gmail archive that
I brought up the same question regarding PropertyChangeEvent/Listener
on 11/20/08 and we exchanged a few e-mails with Emil on the subject on
the dev mailing list.

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


#5

Hey Werner,

袧邪 08.04.10 17:49, Werner Dittmann 薪邪锌懈褋邪:

All,

during the cleanup of the PropertyChangeEvent stuff I found that
SC defined an own exception "PropertyVetoException" that is a subclass
of java's Runtime exception, therefore it is not required to use try/catch
when calling "ConfigurationService.setProperty(...)" methods. In
fact the PropertyVetoException is completely ignored except in one test
case.

This is partially the cause why I've been reluctant to undertake the
refactoring myself. I agree that the property change event name is
confusing, so I am not arguing it's great. Still, it's more than a
matter of a simple s/X/Y substitution, and given that

1) it isn't causing any real problems other than the occasional swearing
when we stumble upon it once a year or so and that

2) we have a number of more serious, user-perceptible issues, that
should arguably have a much higher priority

I've always thought it's probably not worth the hassle. At least not for
the time being.

The real Java PropertyVetoException (java.beans package) is a subclass
of exception, not of Runtime.

That's intentional. The veto mechanism is there "just in case" we need
it and we absolutely didn't want it to add complexity to working with
properties (which should remain as straightforward as possible).

My proposal for the time being: define a new SC specific PropertyVetoException
with a new class name, e.g. PropertyVetoExceptionSc and have it as a
subclass of Runtime as the old SC specific PropertyVetoException. This
name makes it clear that this exception behaves different than the exception
defined in java.beans package.

In the second step we should discuss if an how we use the
real PropertyVetoException instead of just ignoring it and let Felix
report it in case it is thrown.

WDYT?

How about simply renaming both classes to
ConfigProperty[ChangeEvent|VetoException]? This would spare us anything
but the most straightforward refactoring and it would address the naming
ambiguity. We could also add a few extra lines in the the event javadocs
to explain its raison d'etre (or lack thereof :wink: ).

I am aware this is not perfect, but is probably a worthwhile compromise.

How does it sound?

Cheers,
Emil

路路路

Regards,
Werner

Am 07.04.2010 19:40, schrieb Werner Dittmann:

Lubo,

thanks. It seems that it wouldn't do any harm if we clean this
stuff. I'll give it a try and report the outcome.

Regards,
Werner

Am 07.04.2010 19:26, schrieb Lubomir Marinov:

Hello Werner,

Please search through the dev mailing list archive for a brief
discussion/background on the subject - I see in my Gmail archive that
I brought up the same question regarding PropertyChangeEvent/Listener
on 11/20/08 and we exchanged a few e-mails with Emil on the subject on
the dev mailing list.

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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


#6

Hi Emil,

well - see below :wink:

Hey Werner,

袧邪 08.04.10 17:49, Werner Dittmann 薪邪锌懈褋邪:

All,

That's intentional. The veto mechanism is there "just in case" we need
it and we absolutely didn't want it to add complexity to working with
properties (which should remain as straightforward as possible).

How about simply renaming both classes to
ConfigProperty[ChangeEvent|VetoException]? This would spare us anything
but the most straightforward refactoring and it would address the naming
ambiguity. We could also add a few extra lines in the the event javadocs
to explain its raison d'etre (or lack thereof :wink: ).

I am aware this is not perfect, but is probably a worthwhile compromise.

actually I'm already done with the stuff:
- changed to java.beans.Property* in all relevant classes
- introducing a new class PropertyVetoExceptionSc (could rename this
聽聽to ConfigPropertyVetExceoption if this is a better name)
- compile clean and works well - tested already
- thus some classes in "util" are gone and a specific class in "configuration.event"
聽聽package is gone (in my work branch here)

I now that you are doing some more serious work - that's why I try to step in
here and fix some smaller stuff :slight_smile:

Regards,
Werner

路路路

Am 08.04.2010 18:52, schrieb Emil Ivov:

How does it sound?

Cheers,
Emil

Regards,
Werner

Am 07.04.2010 19:40, schrieb Werner Dittmann:

Lubo,

thanks. It seems that it wouldn't do any harm if we clean this
stuff. I'll give it a try and report the outcome.

Regards,
Werner

Am 07.04.2010 19:26, schrieb Lubomir Marinov:

Hello Werner,

Please search through the dev mailing list archive for a brief
discussion/background on the subject - I see in my Gmail archive that
I brought up the same question regarding PropertyChangeEvent/Listener
on 11/20/08 and we exchanged a few e-mails with Emil on the subject on
the dev mailing list.

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


#7

袧邪 08.04.10 19:43, Werner Dittmann 薪邪锌懈褋邪:

actually I'm already done with the stuff:

OK, then.

- changed to java.beans.Property* in all relevant classes
- introducing a new class PropertyVetoExceptionSc (could rename this
聽聽to ConfigPropertyVetoExceoption if this is a better name)

Yes please.

- compile clean and works well - tested already

You can go ahead then. Thanks for taking care of this.

Cheers,
Emil

路路路

- thus some classes in "util" are gone and a specific class in "configuration.event"
聽聽package is gone (in my work branch here)

I now that you are doing some more serious work - that's why I try to step in
here and fix some smaller stuff :slight_smile:

Regards,
Werner

How does it sound?

Cheers,
Emil

Regards,
Werner

Am 07.04.2010 19:40, schrieb Werner Dittmann:

Lubo,

thanks. It seems that it wouldn't do any harm if we clean this
stuff. I'll give it a try and report the outcome.

Regards,
Werner

Am 07.04.2010 19:26, schrieb Lubomir Marinov:

Hello Werner,

Please search through the dev mailing list archive for a brief
discussion/background on the subject - I see in my Gmail archive that
I brought up the same question regarding PropertyChangeEvent/Listener
on 11/20/08 and we exchanged a few e-mails with Emil on the subject on
the dev mailing list.

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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