jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2341) LockManager should use NodeState of the Node itself to remove the PropertyState on unlock
Date Fri, 02 Oct 2009 14:35:23 GMT

    [ 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.


Mime
View raw message