7 Replies Latest reply on Mar 5, 2016 2:39 AM by hchiorean

    Event.PROPERTY_CHANGED semantics

    zcc39r
    zcc39r Feb 24, 2016 5:58 AM

      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?

      • 266 Views
      • Tags:
        • 1. Re: Event.PROPERTY_CHANGED semantics
          hchiorean
          hchiorean Feb 24, 2016 7:53 AM (in response to zcc39r)

          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.

            • Actions
          • 2. Re: Event.PROPERTY_CHANGED semantics
            zcc39r
            zcc39r Feb 24, 2016 9:02 AM (in response to hchiorean)

            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?

              • Actions
            • 3. Re: Event.PROPERTY_CHANGED semantics
              hchiorean
              hchiorean Feb 24, 2016 9:10 AM (in response to zcc39r)

              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.

                • Actions
              • 4. Re: Event.PROPERTY_CHANGED semantics
                zcc39r
                zcc39r Feb 24, 2016 9:33 AM (in response to hchiorean)

                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.

                  • Actions
                • 5. Re: Event.PROPERTY_CHANGED semantics
                  hchiorean
                  hchiorean Feb 25, 2016 2:46 AM (in response to zcc39r)

                  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.

                    • Actions
                  • 6. Re: Event.PROPERTY_CHANGED semantics
                    zcc39r
                    zcc39r Mar 4, 2016 1:32 PM (in response to hchiorean)

                    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.

                      • Actions
                    • 7. Re: Event.PROPERTY_CHANGED semantics
                      hchiorean
                      hchiorean Mar 5, 2016 2:39 AM (in response to zcc39r)

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

                        • Actions