[
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
