You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2012/06/21 18:21:43 UTC
[jira] [Comment Edited] (OAK-144) Implement observation
[ https://issues.apache.org/jira/browse/OAK-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398525#comment-13398525 ]
Michael Dürig edited comment on OAK-144 at 6/21/12 4:21 PM:
------------------------------------------------------------
At revision 1352593 I committed another draft implementation for observation which covers some middle ground of what we [discussed | http://markmail.org/message/osxupy3twc3pyild] on @oak-dev:
* No queueing of events to be delivered
* Pull events from oak-core and calculate them on the fly
* No background thread in oak-core
* Leverage existing NodeStateDiff mechanism
In oak-core the implementation hooks into refresh and remembers a limit (revision) up to which events should be generated. No additional state is kept for observation in oak-core. Clients of oak-core use an instance of {{ChangeExtractor}} which can be obtained from {{Root}} and which allows to extract changes by passing a {{NodeStateDiff}} instance to its
{{getChanges}} method. Each call to {{getChanges}} carries on where the previous call has left.
In oak-jcr each observation listener is associated with a {{ChangeExtractor}} and a timer on a background thread is used to call the {{getChanges}} methods regularly. This is the place where JCR events should be created, filtered and sent to the {{EventListener}}. This is currently work in progress and not yet implemented.
was (Author: mduerig):
At revision 1352593 I committed another draft implementation for observation which covers some middle ground of what we [discussed | http://markmail.org/message/osxupy3twc3pyild] on @oak-dev:
* No queueing of events to be delivered
* Pull events from oak-core and calculate them on the fly
* No background thread in oak-core
In oak-core the implementation hooks into refresh and remembers a limit (revision) up to which events should be generated. No additional state is kept for observation in oak-core. Clients of oak-core use an instance of {{ChangeExtractor}} which can be obtained from {{Root}} and which allows to extract changes by passing a {{NodeStateDiff}} instance to its
{{getChanges}} method. Each call to {{getChanges}} carries on where the previous call has left.
In oak-jcr each observation listener is associated with a {{ChangeExtractor}} and a timer on a background thread is used to call the {{getChanges}} methods regularly. This is the place where JCR events should be created, filtered and sent to the {{EventListener}}. This is currently work in progress and not yet implemented.
> Implement observation
> ---------------------
>
> Key: OAK-144
> URL: https://issues.apache.org/jira/browse/OAK-144
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core, jcr
> Reporter: Michael Dürig
> Assignee: Michael Dürig
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira