You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2013/12/11 11:18:08 UTC

[jira] [Commented] (OAK-1120) Enhance observation mechanism to support Apache Sling

    [ https://issues.apache.org/jira/browse/OAK-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845264#comment-13845264 ] 

Michael Dürig commented on OAK-1120:
------------------------------------

At http://svn.apache.org/r1547592 I added support for registering {{Observer}} instances as OSGi services. Such observers will automatically be notified about all content changes on a background thread. The {{org.apache.jackrabbit.oak.plugins.observation.filter}} package contains various utilities for further processing such content changes. See also OAK-1133, which I took as a guideline for the currently implemented features. 

At http://svn.apache.org/r1550090 and http://svn.apache.org/r1550091 I added support for executing observation listeners off a custom thread pool supplied by the client or container. Sling could thus just register an {{OakExecutor}} which backed by its thread pool support and it will be picked up by Oak for dispatching observation events. 



> Enhance observation mechanism to support Apache Sling
> -----------------------------------------------------
>
>                 Key: OAK-1120
>                 URL: https://issues.apache.org/jira/browse/OAK-1120
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Carsten Ziegeler
>            Assignee: Michael Dürig
>             Fix For: 0.14
>
>         Attachments: OAK-1120.patch
>
>
> The current way the jcr listener work in Sling is not optimal as it reads each and every changed node. So I think it really would be great if we could directly get the information from Oak without the need to additionally process.
> The listener currently:
> 1. Compacts observation events into node added, node changed, and node removed events - it also collects added/changed/removed properties from the events.
> 2. For every added and changed node, it reads the node and the primary node type, the sling:resourceType and sling:resourceSuperType property
> 3. There is a special case, if a node has been added/changed with the name "jcr:content" and the parent node is a file node, then the parent node is reported  as changed/added.
> I've no idea how the current diff mechanism works in Oak, but I would assume that the information for 1. are similar to the result of the diff. I would hope that the properties for 2. are there as well as they need to be diffed against the old value. 3. is more tricky and specific, and I think it would be ok if we would do this in Sling as the ratio of files vs other content is pretty low usually.
> If Oak could provide this information, we could leverage that in Sling and would remove the additional reads - which clearly is an improvement. This would require zero changes in applications based on Sling. If Sling is run on Oak, this implementation is used, otherwis the current JCR based on is used.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)