jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: [jira] Commented: (JCR-922) jcr mapping layer (OCM) should expose lock owner
Date Wed, 16 May 2007 07:28:48 GMT
On 5/16/07, ruchi goel (JIRA) <jira@apache.org> wrote:
>
>
>     [
> https://issues.apache.org/jira/browse/JCR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496202]
>
> ruchi goel commented on JCR-922:
> --------------------------------
>
> If we go by your first comment ,We need the following :
> 1. Wrapper class for Lock.
> 2. The method lock() should return object  of the wrapper class which can
> be used by caller to obtain lockowner.
>
> Does it not break backward compatability ? I mean the same method now
> returning a different object type ? Is that acceptable ?



Yes. We are still under dev.

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message