[
https://issues.apache.org/jira/browse/JCR-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761595#action_12761595
]
Jukka Zitting commented on JCR-2341:
------------------------------------
> i'd be rather reluctant to expose NodeState to api client...
Agreed. I wonder if the current code could be refactored in some way to avoid
this.
This seems like one of the cases where the fact that our Impl classes both
implement the JCR interfaces and contain notable amounts of underlying logic
and data structures. The new task-oriented JCR 2.0 interfaces like LockManager
make the current design harder to use than before, as all the underlying state
related to a given operation (in this case the active NodeState instance) is no
longer directly accessible as a private member of the object being accessed.
> LockManager should use NodeState of the Node itself to remove the
> PropertyState on unlock
> -----------------------------------------------------------------------------------------
>
> Key: JCR-2341
> URL: https://issues.apache.org/jira/browse/JCR-2341
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.6.0
> Reporter: Claus Köll
> Assignee: Claus Köll
> Fix For: 1.6.1
>
> Attachments: JCR-2341.patch
>
>
> If you try to unlock and remove a node the NodeState can be run out of sync
> between the two operations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
