jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-387) Clarify behavior/state of Root and Tree after calling ContentSession#close()
Date Fri, 19 Oct 2012 09:42:11 GMT

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

Michael Dürig commented on OAK-387:

bq. A better approach would be to keep a reference to the {{ContentSession}} ...

This would work but I'm not convinced this is better since it introduces additional coupling.
Currently the {{Root}} implementation does not have a dependency on {{ContentSession}}. Maybe
we should introduce some kind of a session life cycle listener here. This might be useful
in other places too.
> Clarify behavior/state of Root and Tree after calling ContentSession#close()
> ----------------------------------------------------------------------------
>                 Key: OAK-387
>                 URL: https://issues.apache.org/jira/browse/OAK-387
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: angela
> quickly discussed this topic with jukka today in the office.
> as far as i know the API contract does currently not specify what happens
> to (the state of) a Root or Tree once the ContentSession has been closed.
> if i am not mistaken, the current implementation would just loose 
> the permissions that were granted to the original subject... but that's
> rather a coincidence (and i didn't test it to verify that's really the case)
> possible solutions could be:
> - upon session closure the root/tree becomes invalid (invalidstate) and throws
> - the root/tree are still valid but doesn't have the original permissions
>   any more -> default permissions for empty-subject would apply
> - ...
> whatever solution we may prefer in the end, i think that API contract should
> state the expected behavior (even if it was "undefined") and we should have tests verifying
the current implementation does what we think it should do.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message