[jira] [Created] (OAK-1133) Observation listener PLUS

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

Alexander Klimetschek created OAK-1133:
------------------------------------------

             Summary: Observation listener PLUS
                 Key: OAK-1133
                 URL: https://issues.apache.org/jira/browse/OAK-1133
             Project: Jackrabbit Oak
          Issue Type: New Feature
          Components: commons, jcr
            Reporter: Alexander Klimetschek


Oak should provide an *extended and efficient JCR observation listener* mechanism to support common use cases not handled well by the restricted options of the JCR observation. Those cases require listeners to register much more broadly and then filter out their specific cases themselves, thus putting too many events into the observation system and creating a huge overhead due to asynchronous access to the modified JCR data to do the filtering. This easily is a big performance bottleneck with many writes and thus many events.

Previous discussions [on the list|http://markmail.org/message/oyq7fnfrveceemoh] and in OAK-1120.

The goals should be:
* performance: handle filtering as early as possible, during the commit, where access to the modified data is already present
* provide robust implementation for typical filtering cases
* provide an asynchronous listener mechanism as in JCR
* minimize effect on the lower levels on Oak (a visible addition in oak-commons or oak-jcr should be enough)
* for delete events, allow filtering on the to-be-deleted data (currently not possible in jcr listeners that run after the fact)
* if possible: design as an extension of the jcr observation to simplify migration for existing code
* if possible: provide an intelligent listener that can work with pure JCR (aka Jackrabbit 2) as well, by falling back to in-listener-filtering

Typical filtering cases:
- paths with globbing support (for example /content/foo/*/something)
- check for property values (equal, not equal, contains etc.), most importantly
sling:resourceType in Sling apps
- allow to check properties on child nodes as well, typically jcr:content
- node types (already in jcr observation)
- created/modified/deleted events, separate from move/copy
- and more... a custom filter should be possible to pass through (with similar access as the {{Observer}})



--
This message was sent by Atlassian JIRA
(v6.1#6144)