Event.PROPERTY_CHANGED semantics

[zcc39r]

Having WildFly 8.2.0 and ModeShape 4.5.0 I'm trying to observe changing properties of nt:resource node. I'm setting jcr:data and jcr:mimeType properties with same values they already have and calling a session.save(). So I guess that these properties were not changed. But corresponding listener detects that three properties changed - jcr:lastModified,  jcr:lastModifiedBy, jcr:mimeType:

2016-02-24 09:34:11,962 DEBUG [org.jboss.as.config] (MSC service thread 1-5) Configured system properties:

...

java.runtime.version = 1.7.0_80-b15

...

12:22:37,026 DEBUG [org.modeshape.jcr.JcrObservationManager] (modeshape-event-dispatcher-3-thread-7) Processing change: Changed property {http://www.jcp.org/jcr/1.0}lastModified on node '5e31bb87505d64d3ca2ef8-9669-4dea-9134-958ddb16d4c4' at path /{}books/{}13/{httpwww.jcp.orgjcr1.0}content from:{http://www.jcp.org/jcr/1.0}lastModified = 2016-02-24T12:22:05.305+03:00 to:{http://www.jcp.org/jcr/1.0}lastModified =2016-02-24T12:22:36.967+03:00

12:22:37,027 DEBUG [org.modeshape.jcr.JcrObservationManager] (modeshape-event-dispatcher-3-thread-7) Processing change: Changed property {http://www.jcp.org/jcr/1.0}lastModifiedBy on node '5e31bb87505d64d3ca2ef8-9669-4dea-9134-958ddb16d4c4' at path /{}books/{}13/{httpwww.jcp.orgjcr1.0}content from:{http://www.jcp.org/jcr/1.0}lastModifiedBy = admin to:{http://www.jcp.org/jcr/1.0}lastModifiedBy = admin

12:22:37,027 DEBUG [org.modeshape.jcr.JcrObservationManager] (modeshape-event-dispatcher-3-thread-7) Processing change: Changed property {http://www.jcp.org/jcr/1.0}mimeType on node '5e31bb87505d64d3ca2ef8-9669-4dea-9134-958ddb16d4c4' at path /{}books/{}13/{httpwww.jcp.orgjcr1.0}content from:{http://www.jcp.org/jcr/1.0}mimeType = application/xml to:{http://www.jcp.org/jcr/1.0}mimeType = application/xml

When JRE is switched to 1.8, listener detects that two properties changed - jcr:lastModifiedBy, jcr:data:

2016-02-24 13:17:47,196 DEBUG [org.jboss.as.config] (MSC service thread 1-7) Configured system properties:

...

java.runtime.version = 1.8.0_72-b15

...

13:18:28,534 DEBUG [org.modeshape.jcr.JcrObservationManager] (modeshape-event-dispatcher-3-thread-7) Processing change: Changed property {http://www.jcp.org/jcr/1.0}lastModified on node '5e31bb87505d64612b8e51-3ee4-4564-be23-4374c29faf69' at path /{}books/{}14/{httpwww.jcp.orgjcr1.0}content from:{http://www.jcp.org/jcr/1.0}lastModified = 2016-02-24T13:17:18.054+03:00 to:{http://www.jcp.org/jcr/1.0}lastModified = 2016-02-24T13:18:28.450+03:00                                                                                                                                         

13:18:28,536 DEBUG [org.modeshape.jcr.JcrObservationManager] (modeshape-event-dispatcher-3-thread-7) Processing change: Changed property {http://www.jcp.org/jcr/1.0}data on node '5e31bb87505d64612b8e51-3ee4-4564-be23-4374c29faf69' at path /{}books/{}14/{httpwww.jcp.orgjcr1.0}content from:{http://www.jcp.org/jcr/1.0}data = binary (3,11KB, SHA1=67f9dfbaeb1d6968209dbfbc8fa801999f4f0b46) to:{http://www.jcp.org/jcr/1.0}data = binary (3,11KB, SHA1=67f9dfbaeb1d6968209dbfbc8fa801999f4f0b46)

I agree that jcr:lastModified changed automatically when session was saved. But why jcr:lastModifiedBy, jcr:mimeType and jcr:data considered changed? More generally what is the semantics of "property change" as implemented in ModeShape? Should this semantics be independent of JRE version?

[hchiorean]

jcr:lastModifiedBy and jcr:lastModified are *always* set together on each session.save(), regardless of the actual data set on a nodes, as long as that node is mix:lastModified

jcr:mimeType should only be set if mime type detection is enabled in the repository configuration and only when a new/different byte[] content is set on a node's property. If you're setting the same byte[] multiple times, only the first time you're setting the value on the node should the event be fired. Subsequent changes to same value should not raise the event. Also, if you change the byte[] content of a node, the event should be raised because the mime-type has to be recalculated.

jcr:data should only be raised as a property changed event together with jcr:mimetype. i.e., they should normally be raised together.

With the exception of thread timing, I don't know why the event behavior would be different between JREs. Normally, it shouldn't be. However, ModeShape 4 was built and requires JDK 7. No JDK 8 testing has been performed, nor will it be.

Starting with 4.6.0.Final, all development will switch to ModeShape 5 which runs and requires JDK 8. So if you find any bugs/issues and raise JIRAs for them, they will be tested & fixed in ModeShape 5.

[zcc39r]

So JRE 7-based behaviour looks consistent with your clarifications. Thank you!

Indeed, jcr:lastModifiedBy value is identical to the value before session.save(). So what's the reason to fire a property changed event for this?

[hchiorean]

As mentioned above, the two lastModified properties are set together on each session.save() (this perfectly acceptable per JCR #3.7.11.8). The fact that they are set will trigger a PROPERTY_CHANGE_EVENT for each of them.

The alternative for the jcr:lastModifiedBy is to always read & compare the old with the new value (the currently logged user of the session). ModeShape chooses not to do this to avoid an extra read.

[zcc39r]

Well, the reason is performance. So for mix:lastModified "changed" equals "set". But why not for nt:resource and other node types? May be performance benefit will be achieved, if extra read for jcr:data will be avoided and set without actual change will fire property changed event?

In fact, there is one "changed" semantics for mix:lastModified and another for other types. It sounds not good.

[hchiorean]

I agree that the behavior should be consistent across property changed events (with respect to no-ops and jcr:lastModifiedBy), so I've opened https://issues.jboss.org/browse/MODE-2572 which I'll look at for 5.0.

[zcc39r]

Filed [MODE-2580] Property changed events should only be fired if the property value actually changes along with patch for JcrObservationManagerTest which contains a test demonstrating false event firing for jcr:data.

[hchiorean]

thanks, we'll try to look at it for ModeShape 5.