jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-153) Split the CommitHook interface
Date Tue, 26 Jun 2012 14:21:44 GMT

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

Jukka Zitting commented on OAK-153:
-----------------------------------

The lifecycle of such hooks is up to the deployment - oak-core only cares about the hooks
that are made available to it by the deployment at any given point of time. For example in
an OSGi deployment oak-core would use the whiteboard pattern to access such hooks.

It should be fine for a class to implement both interfaces if it wants to. But note that,
as explained above, there are few guarantees about causality between before- and afterCommit()
calls. Thus there isn't much that such a combined class could do that two independent classes
couldn't.
                
> Split the CommitHook interface
> ------------------------------
>
>                 Key: OAK-153
>                 URL: https://issues.apache.org/jira/browse/OAK-153
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>
> The {{CommitHook}} interface has two methods, {{beforeCommit()}} and {{afterCommit()}},
since the symmetry originally seemed like a good idea. However, in practice these methods
are not really so symmetric after all.
> For example, unlike {{afterCommit()}} the {{beforeCommit()}} method may end up being
called multiple times for a given changeset if it needs to be repeatedly rebased or otherwise
revised before it can be committed. There isn't even any guarantee that a particular changeset
on which {{beforeCommit()}} has been called ever gets committed. And on the other hand there
are good reasons to avoid calling {{afterCommit()}} on each and every commit that has been
made. Instead it could be called only every now and then to cover larger sets of changes.
> Thus I'd like to split the {{CommitHook}} interface to two parts that I'd tentatively
call {{CommitEditor}} and {{Observer}}.

--
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

        

Mime
View raw message