You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2012/10/18 20:36:02 UTC
[jira] [Created] (OAK-387) Clarify behavior/state of Root and Tree
after calling ContentSession#close()
angela created OAK-387:
--------------------------
Summary: 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
[jira] [Assigned] (OAK-387) Clarify behavior/state of Root and Tree
after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig reassigned OAK-387:
---------------------------------
Assignee: Michael Dürig
> 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
> Assignee: Michael Dürig
>
> 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
[jira] [Resolved] (OAK-387) Clarify behavior/state of Root and Tree
after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig resolved OAK-387.
-------------------------------
Resolution: Fixed
Fix Version/s: 0.6
Fixed at revision 1400068
> 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
> Assignee: Michael Dürig
> Fix For: 0.6
>
>
> 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
[jira] [Commented] (OAK-387) Clarify behavior/state of Root and
Tree after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Comment Edited] (OAK-387) Clarify behavior/state of Root
and Tree after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479895#comment-13479895 ]
Michael Dürig edited comment on OAK-387 at 10/19/12 9:04 AM:
-------------------------------------------------------------
Currently all {{Tree}} s and {{Root}} s that haven been created from a {{ContentSession}} stay "valid" after the content session has been closed. So in a way the current behaviour is closest to "undefined". If we want to change this and make them "invalid" we'd need to track all {{Root}} s spawned of from a content session and also "close" them once the content session is closed. Not sure whether that is worth it. What would be the consequences/problems with either solutions?
was (Author: mduerig):
Currently all {{Tree}} s and {{Root}} s that haven been created from a {{ContentSession}} stay "valid" after the content session has been closed. So in a way the current behaviour is closest to "undefined". If we want to change this and make them "invalid" we'd need to track all {{Root}}s spawned of from a content session and also "close" them once the content session is closed. Not sure whether that is worth it. What would be the consequences/problems with either solutions?
> 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
[jira] [Comment Edited] (OAK-387) Clarify behavior/state of Root
and Tree after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479895#comment-13479895 ]
Michael Dürig edited comment on OAK-387 at 10/19/12 9:04 AM:
-------------------------------------------------------------
Currently all {{Tree}} s and {{Root}} s that haven been created from a {{ContentSession}} stay "valid" after the content session has been closed. So in a way the current behaviour is closest to "undefined". If we want to change this and make them "invalid" we'd need to track all {{Root}}s spawned of from a content session and also "close" them once the content session is closed. Not sure whether that is worth it. What would be the consequences/problems with either solutions?
was (Author: mduerig):
Currently all {{Tree}}s and {{Root}}s that haven been created from a {{ContentSession}} stay "valid" after the content session has been closed. So in a way the current behaviour is closest to "undefined". If we want to change this and make them "invalid" we'd need to track all {{Root}}s spawned of from a content session and also "close" them once the content session is closed. Not sure whether that is worth it. What would be the consequences/problems with either solutions?
> 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
[jira] [Commented] (OAK-387) Clarify behavior/state of Root and
Tree after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479917#comment-13479917 ]
Michael Dürig commented on OAK-387:
-----------------------------------
Agrees, sounds like the best solution.
> 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
[jira] [Commented] (OAK-387) Clarify behavior/state of Root and
Tree after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479895#comment-13479895 ]
Michael Dürig commented on OAK-387:
-----------------------------------
Currently all {{Tree}}s and {{Root}}s that haven been created from a {{ContentSession}} stay "valid" after the content session has been closed. So in a way the current behaviour is closest to "undefined". If we want to change this and make them "invalid" we'd need to track all {{Root}}s spawned of from a content session and also "close" them once the content session is closed. Not sure whether that is worth it. What would be the consequences/problems with either solutions?
> 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
[jira] [Commented] (OAK-387) Clarify behavior/state of Root and
Tree after calling ContentSession#close()
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479909#comment-13479909 ]
Jukka Zitting commented on OAK-387:
-----------------------------------
There are two problems with leaving those resources in a "valid" state after the session is gone:
* When the authenticated session is closed, the resources associated with it must no longer have the associated access privileges. For example, a Root of an admin session must no longer be allowed to commit() as an admin after the session has been closed.
* There should be some way (other than relying on garbage collection) to release large transient resources like uncommitted binaries or unmerged branches when they are no longer needed. If the close() method on ContentSession does not limit the lifecycle of associated Roots and Trees, then those interfaces would need to also be Closeable.
bq. If we want to change this and make them "invalid" we'd need to track all Root s spawned of from a content session and also "close" them once the content session is closed.
A better approach would be to keep a reference to the ContentSession object in the associated Root and Tree objects, and have them check the status of the session whenever used for something that requires something covered by the above two points.
> 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
[jira] [Commented] (OAK-387) Clarify behavior/state of Root and
Tree after calling ContentSession#close()
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479915#comment-13479915 ]
Jukka Zitting commented on OAK-387:
-----------------------------------
bq. additional coupling
We can avoid that with a similar mechanism as we're using with the namespace and node type registries: Instead of having a direct {{ContentSessionImpl}} reference in {{RootImpl}}, we could add a protected {{checkStatus()}} method that by default does nothing, but gets overridden in an anonymous subclass in {{ContentSessionImpl}}.
> 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
[jira] [Comment Edited] (OAK-387) Clarify behavior/state of Root
and Tree after calling ContentSession#close()
Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479917#comment-13479917 ]
Michael Dürig edited comment on OAK-387 at 10/19/12 9:48 AM:
-------------------------------------------------------------
Agreed, sounds like the best solution.
was (Author: mduerig):
Agrees, sounds like the best solution.
> 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