Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: observation
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      477

      Description

      Method events as currently defined in 6.10.4.3 (RC17) are IMO under-specified.

      there are several open issues with the current specification:

      • sequence of state change and method events is unclear (issue# 462)
      • getMethodInfo issues (issue# 461)
        binary/stream method arguments are problematic (at best) and put
        a heavy burden on an implementation; e.g. on import an implementation
        would need to spool the contents of a (potentially very large) xml
        stream beforehand in order to make it available to the *IMPORT method
        event. similar issues exist with the SET_PROPERTY method event.
      • there's no method event for Session/Workspace#getImportContentHandler;
        it's unclear how SAX events could be represented in the current method
        event design.
      • CHANGE_MIXINS method event: unclear how this maps to the Node.addMixin and
        .removeMixin methods; what are the parameters? should probably be replaced
        with separate method events, e.g. ADD_MIXIN & REMOVE_MIXIN
      • granularity of (transient) method events is unclear: is an application allowed
        to consolidate method events? e.g. consider the following method calls:

      node.setProperty("foo", "bar");
      node.setProperty("foo", null);

      or

      session.move("/foo", "/bar");
      session.move("/bar", "/bar1");

      or

      workspace.move("/foo", "/bar");
      workspace.move("/bar", "/bar1");

      how many method events would be generated by each of the above examples?

      this is just a random list of issues i found, there are probably more than those
      listed here.

      in the light of the issues with the current method event design i'd like to raise
      the question whether we really need method events. what are the use cases requiring
      method events? IIRC the most important use case is detecting move operations.

      are there more? detecting move operations could IMO be handled by the observation/event
      userdata feature. it would shift the responsibility to the application, but is this
      a problem?

        Issue Links

          Activity

          Hide
          fguillaume added a comment -

          Just to recap, my personal primary use case for method events is to be able to be able to
          maintain/invalidate a cache. So not all data has to be present in the event itself, and granularity doesn't
          have to be ultra-fine.

          Show
          fguillaume added a comment - Just to recap, my personal primary use case for method events is to be able to be able to maintain/invalidate a cache. So not all data has to be present in the event itself, and granularity doesn't have to be ultra-fine.
          Hide
          Peeter Piegaze added a comment -

          Issue 461 has been marked as wontfix, but I would like to add Florent's comment on that issue to this
          one, because I think it sums up the issue very well:

          (Florent from issue 461)
          "Returning the method name seems wrong to me. We don't want to express what method was precisely
          called,
          we want to express the semantics of what that call did.
          I haven't looked in detail, but there may be several methods with different names which have the exact
          same
          semantics from an event's point of view. For instance I want node.setProperty and property.setValue to
          be
          logged the same way, there's no need to distinguish them. Etc.

          Similarly, getMethodInfo returning the exact parameter names to the call seems wrong too. We want to
          take a
          step back and generate events with synthesized (although precise) information in them.

          So just turning method events into a kind of audit of all the API calls will not be a simplification for a
          programmer needing to treat these events. He might as well wrap the JCR session in a reflection-based
          logger
          that logs all that. What's needed for a programmer that uses these events is a precise list of the low-
          level
          semantic changes that can occur in the database (at the level of a method call). There will be some
          form of
          redundancy with a full listing of the API, but this will be much smaller and manageable and
          comprehensible
          by the programmer."

          Show
          Peeter Piegaze added a comment - Issue 461 has been marked as wontfix, but I would like to add Florent's comment on that issue to this one, because I think it sums up the issue very well: (Florent from issue 461) "Returning the method name seems wrong to me. We don't want to express what method was precisely called, we want to express the semantics of what that call did. I haven't looked in detail, but there may be several methods with different names which have the exact same semantics from an event's point of view. For instance I want node.setProperty and property.setValue to be logged the same way, there's no need to distinguish them. Etc. Similarly, getMethodInfo returning the exact parameter names to the call seems wrong too. We want to take a step back and generate events with synthesized (although precise) information in them. So just turning method events into a kind of audit of all the API calls will not be a simplification for a programmer needing to treat these events. He might as well wrap the JCR session in a reflection-based logger that logs all that. What's needed for a programmer that uses these events is a precise list of the low- level semantic changes that can occur in the database (at the level of a method call). There will be some form of redundancy with a full listing of the API, but this will be much smaller and manageable and comprehensible by the programmer."
          Hide
          Peeter Piegaze added a comment -

          The following subparts of this issue have been fixed:

          CHANGE_MIXIN replaced by ADD_MIXIN and REMOVE_MIXIN

          Sequence of method vs. state-change events specified:
          "6.10.6.1 Event Ordering
          In both asynchronous and journaled observation, within a bundle, a state-change event must never
          precede the method event that caused it."

          Heavy-weight params can be omitted:
          6.10.4.5 MethodInfo
          [bullet 4] If the parameter is another class of object then the value is either that object or null. An
          implementation should only use null in cases where keeping the object reference in the Event is
          impractical for performance or other resource-related reasons. For example, an implementation may
          choose to use null for objects of type javax.jcr.Binary.

          Require method events FOR JCR API methods state change events are best effort (eg big move)

          Still to do on this issue: as per costa mesa F2F, the full set of method events has yet to be defined.

          Show
          Peeter Piegaze added a comment - The following subparts of this issue have been fixed: CHANGE_MIXIN replaced by ADD_MIXIN and REMOVE_MIXIN Sequence of method vs. state-change events specified: "6.10.6.1 Event Ordering In both asynchronous and journaled observation, within a bundle, a state-change event must never precede the method event that caused it." Heavy-weight params can be omitted: 6.10.4.5 MethodInfo [bullet 4] If the parameter is another class of object then the value is either that object or null. An implementation should only use null in cases where keeping the object reference in the Event is impractical for performance or other resource-related reasons. For example, an implementation may choose to use null for objects of type javax.jcr.Binary. Require method events FOR JCR API methods state change events are best effort (eg big move) Still to do on this issue: as per costa mesa F2F, the full set of method events has yet to be defined.
          Hide
          Peeter Piegaze added a comment -

          Status changed to REOPEN: Issue not yet decided

          Show
          Peeter Piegaze added a comment - Status changed to REOPEN: Issue not yet decided
          Hide
          Peeter Piegaze added a comment -

          Status changed to REOPEN: Issue not yet decided

          Show
          Peeter Piegaze added a comment - Status changed to REOPEN: Issue not yet decided
          Hide
          Peeter Piegaze added a comment -

          As per November 2008 conf call method events have been removed

          Show
          Peeter Piegaze added a comment - As per November 2008 conf call method events have been removed

            People

            • Assignee:
              jsr-283-issues
              Reporter:
              stefan_guggisberg
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: