[jira] Commented: (JCR-922) jcr mapping layer (OCM) should expose lock owner

["Christophe Lombart (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495901 ] 

Christophe Lombart commented on JCR-922:
----------------------------------------

Just 2 comments : 

1/ Concerning the method lock, it should be better to return an object instead of an hashmap. This object could be similar to the Lock object defined in the JCR spec but this is tedious to create a wrapper class for this kind of JCR object. We have exaclty the same kind of issues with the versionning support. 

2/ Supporting the mix:lockable node type :  I understand your issue. The ocm framework has to have a better secondary node type support in term of field definition. I think we have to list the different use cases before taking a decision. 


> jcr mapping layer (OCM) should expose lock owner
> ------------------------------------------------
>
>                 Key: JCR-922
>                 URL: https://issues.apache.org/jira/browse/JCR-922
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jcr-mapping
>    Affects Versions: 1.3
>            Reporter: ruchi goel
>             Fix For: 1.3
>
>
> jcr mapping layer 's  persistencemanager.java  does not expose an API for returning lockowner. Ideally   , the following method 
> public String lock(final String absPath, final boolean isDeep, final boolean isSessionScoped) 
> should return a hashmap/String array containing locktoken as well as lockowner. 
> I tried having lockowner as a field in my java object and mapping it to jcr:lockOwner , so that I can just use getLockOwner() . But the problem is this property gets introduced in the node only if  the node is locked. So, when I try to insert a node , before I can even lock it , the insertion fails since there is no property like jcr:lockOwner   till then . 
> So, I feel there is need for the above API. It is ok to have it exposed via separate call in order to maintain backward compatability

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.