Add a method to detect which properties were changed in a reload about owner HOT 26 CLOSED

👍

I thought about that, to have a listener that receives a PropertyChangeEvent containing { key, newValue, oldValue) (newValue and oldValue may be null to mean that a property has been added or removed)
Would that be ok?

cfg.addPropertyChangeListener(new PropertyChangeListener() {
    void propertyChanged(PropertyChangeEvent evt) {
         //....
    }
}

The above will get triggered for every property changed. (when reload happens it will be triggered as many times as the number of the properties loaded that have been changed)

Another option would be to register for a specific propertyKeyChange:

cfg.addPropertyChangeListener(new PropertyKeyChangeListener("foobar") {
    void propertyKeyChanged(PropertyChangeEvent evt) {
         //....
    }
}

The above will only be triggered when a specific property is changed.

I think I'll implement both. It should not be difficult.

Would this cover your use case?

from owner.

On master branch, owner should be able to hot-reload properties also when they are loaded from the classpath. I need to test this more, and update the documentation (that states the opposite)

from owner.

Also, it would be nice to allow the listener to rollback the property change (or the entire reload), for instance, throwing a PropertyChangeRollbackException, or ReloadRollbackException, what do you think?

This can work as a programmable 'validation' mechanism.

from owner.

Yes, it would be cool :) but you will also need to implement some sort of
two phase commit: first check all the listeners, when everybody is okay
then execute the change.

from owner.

That's not the hard part, I think. And that was exactly what I had in mind.

But there are some cases to take in mind.

Suppose property X is changed, and the value passes from A to B.

There are two listeners registered for changes on property X.

1st listener gets notified, and for him X := B.
2nd listener gets notified and throws the exception to say "no, roll back X := A"
3rd listener doesn't get notified, since the 2nd cancelled the change.

So... we have this situation.
For the 1st listener X is equal to B. For the 2nd and 3rd listeners X is equal to A...

So... troubles :)

One could send another event to 1st listener to say that X gets assigned back to A... but... what if then the 1st listener throws an exception? .... it's a matter to save "capra e cavoli" ;)

from owner.

Yeah, and that's exactly the reason why I was suggesting a two-phase commit
approach: first you ask all the involved listeners "are you ready to commit
to this change?" and if all agree then you propagate the change.
On Jul 30, 2013 8:38 PM, "Luigi R. Viggiano" [email protected]
wrote:

That's not the hard, I think.

But there are some cases to take in mind.

Suppose property X is change, and the value passes from A to B.

There are two listeners registered for changes on property X.

1st listener gets notified, and for him X := B.
2nd listener gets notified and throws the exception to say "no, roll back
X := A"
3rd listener doesn't get notified, since the 2nd cancelled the change.

So... we have this situation.
For the 1st listener X is equal to B. For the 2nd and 3rd listeners X is
equal to A...

So... troubles :)

One could send another event to 1st listener to say that X gets assigned
back to A... but... what if then the 1st listener throws an exception? ....
it's a matter to save "capra e cavoli" ;)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-21816818
.

from owner.

So it can be something like:

cfg.addPropertyChangeListener(new PropertyChangeListener() {
    void beforePropertyChange(PropertyChangeEvent evt) throws Whatever... {
         //....
    }

   void afterPropertyChange(PropertyChangeEvent evt) {  // throws nothing
   }
}

In this way one received the event before the change and have the chance to rollback throwing an exception, but he can only assume that the property is actually changed on the method afterPropertyChange().

Sounds good?

from owner.

I would probably use a different naming, such as:

cfg.addPropertyChangeListener(new PropertyChangeListener() {
void preparePropertyChange(PropertyChangeEvent evt) throws Whatever... {
//....
}

void commitPropertyChange(PropertyChangeEvent evt) { // throws nothing
//....
}}

It looks more clear to me as it sounds much more like a 2 phase commit:

• on preparePropertyChange you have the opportunity to vote NO to a
  property change: if you don't then it means you are fully prepared to
  commit to this change
• on commitPropertyChange you will have to commit the change

The system will first ask to all participant (listeners) to be prepared for
the change: if all say yes, then he commits every one of them.
Cheers,

Bruno

On Wed, Jul 31, 2013 at 1:16 PM, Luigi R. Viggiano <[email protected]

wrote:

So it can be something like:

cfg.addPropertyChangeListener(new PropertyChangeListener() {
void beforePropertyChange(PropertyChangeEvent evt) throws Whatever... {
//....
}

void afterPropertyChange(PropertyChangeEvent evt) { // throws nothing
}}

In this way one received the event before the change and have the chance
to rollback throwing an exception, but he can only assume that the property
is actually changed on the method afterPropertyChange().

Sounds good?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-21857438
.

from owner.

@lviggiano - Can I use master build to detect property change? I just need to know which property was changed in my application.

from owner.

@lviggiano - When I build from master, 12 tests are failing. Can I skip the tests and build it?

from owner.

The feature is still a work in progress, so, it's not completed yet (mostly unimplemented). I'll work on this asap to complete the feature.

BTW tests on master branch should not be failing. Can you post your build log or send it to me by email?

As far as I know all tests should be green.

See:
https://aeonbits.ci.cloudbees.com/job/owner-api/
https://travis-ci.org/lviggiano/owner
http://sheldon.dyndns.tv:9000/dashboard/index/org.aeonbits.owner:owner

There is one multi-thread test that sometimes fails due to the fact that the test is not perfect synchronizing delays before to check results. Afaik this is the only test that produces build failures, and I need to look into it.

from owner.

I just emailed you the logs.
I would really appreciate if you can add this feature asap.

from owner.

I'll do. Thanks for the logs. I'm planning next week to start again coding
on this project. Still in holidays.
Il giorno 06/set/2013 08:52, "vaibhavk81" [email protected] ha
scritto:

I just emailed you the logs.
I would really appreciate if you can add this feature asap.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-23922155
.

from owner.

@vaibhavk81 I'm actively working to this feature those days. It should not take long time.
About your logs, I think you have a dirty copy of the master branch, since I am not noticing failing tests; try a fresh checkout.

from owner.

Thanks!
I will wait for the new feature and then get the latest from master.

~Vaibhav

On Wed, Sep 11, 2013 at 1:53 PM, Luigi R. Viggiano <[email protected]

wrote:

@vaibhavk81 https://github.com/vaibhavk81 I'm actively working to this
feature those days. It should not take long time.
About your logs, I think you have a dirty copy of the master branch, since
I am not noticing failing tests; try a fresh checkout.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-24220586
.

from owner.

I think the implementation is almost ready, I need to write some more tests and the documentation to close this issue. It's early to say "done", but you can start testing in non-critic environments, if you like.

See Mutable:

    /**
     * Adds a {@link PropertyChangeListener} to the Mutable interface.
     *
     * @param listener the listener to be added.
     * @since 1.0.5
     */
    void addPropertyChangeListener(PropertyChangeListener listener);

PropertyChangeListener comes from the JRE libraries.

I will later add a method to register on a single propertyName:

    void addPropertyChangeListener(String propertyName, PropertyChangeListener listener);

I also extended the PropertyChangeListener with TransactionalPropertyChangeListener that exposes an additional method:

/**
 * A Listener that is aware of properties changes.
 *
 * @author Luigi R. Viggiano
 */
public interface TransactionalPropertyChangeListener extends PropertyChangeListener {

    /**
     * This method is invoked before the property is changed. When this method is invoked we cannot assume that the
     * change is effective, since some listener can ask to roll back the change operation.
     *
     * @param evt the {@link PropertyChangeEvent event} of property change.
     * @throws RollbackOperationException when the listener wants to rollback the change on the property intercepted
     * @throws RollbackBatchException     when the listener wants to rollback the entire set of changes if executed in the
     *                                    batch.
     */
    void beforePropertyChange(PropertyChangeEvent evt) throws RollbackOperationException, RollbackBatchException;

}

Test cases are here:

• PropertyChangeListenerTest
• PropertyChangeListenerOnReloadTest

In particular I need to test more the reload().

from owner.

Testing is complete.

Things to do:

• method void addPropertyChangeListener(String propertyName, PropertyChangeListener listener);
• tests for above method
• documentation on the website

@vaibhavk81 if you want to start using the feature, you can now.
Latest jars are here: http://oss.sonatype.org/content/repositories/snapshots/org/aeonbits/owner/owner/1.0.5-SNAPSHOT/
Latest javadocs etc are here: http://owner.newinstance.it/1.0.5-SNAPSHOT/
Good luck ;)

from owner.

Thanks a lot!
I will test it out and let you know.

~Vaibhav

On Fri, Sep 13, 2013 at 11:57 PM, Luigi R. Viggiano <
[email protected]> wrote:

Testing is complete.

Things to do:

• documentation on the website
• method void addPropertyChangeListener(String propertyName,
  PropertyChangeListener listener);
• tests for above method.

@vaibhavk81 https://github.com/vaibhavk81 if you want to start using
the feature, you can now. Good luck ;)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-24414668
.

from owner.

I completed a draft implementation for PropertyChangeListeners, @bbossola and @vaibhavk81, if you want to have a look at the code or the unit tests regarding the programming interfaces (internals may still change before the 1.0.5 release) you can refer to the unit tests and javadocs.

from owner.

@vaibhavk81 I found out that some tests were failing on Windows boxes, since I am testing only on Linux and Mac OS X I didn't notice the problem before.

Current master should build fine on Windows too.

I'm very close to 1.0.5 release which will contain this feature.

from owner.

Added documentation page:

http://owner.aeonbits.org/docs/event-support/

Tomorrow I will release 1.0.5

from owner.

Thanks a lot!

~Vaibhav

On Mon, Oct 7, 2013 at 7:05 AM, Luigi R. Viggiano
[email protected]:

Added documentation page:

http://owner.aeonbits.org/docs/event-support/

Tomorrow I will release 1.0.5

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-25810692
.

from owner.

@bbossola tomorrow I'll probably release 1.0.5 with this feature implemented. Can you please have a look and review the interfaces for any design suggestion?

http://owner.newinstance.it/1.0.5-SNAPSHOT/xref/index.html
http://owner.newinstance.it/1.0.5-SNAPSHOT/apidocs/index.html

the package is org.aeonbits.owner.event. The PropertyChangeEvent and PropertyChangeListener comes from java.beans.

from owner.

1.0.5 released. @bbossola @vaibhavk81 you can update your app with the latest version.

from owner.

Will do. Thanks!

Regards,
Vaibhav Khare

Sent from my iPhone

On Oct 9, 2013, at 8:14 AM, "Luigi R. Viggiano" [email protected] wrote:

1.0.5 released. @bbossola @vaibhavk81 you can update your app with the latest version.

—
Reply to this email directly or view it on GitHub.

from owner.

Thx looks cool!
On Oct 9, 2013 4:40 PM, "Luigi R. Viggiano" [email protected]
wrote:

1.0.5 released. @bbossola https://github.com/bbossola @vaibhavk81https://github.com/vaibhavk81you can update your app with the latest version.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-25979402
.

from owner.