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

Mime
View raw message