You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Flavel Heyman (JIRA)" <ji...@apache.org> on 2016/01/22 00:42:39 UTC

[jira] [Updated] (JCR-3946) LockImpl getLockToken missing scenario

     [ https://issues.apache.org/jira/browse/JCR-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavel Heyman updated JCR-3946:
-------------------------------
    Affects Version/s:     (was: 2.9.1)
                       2.6.5
                       2.10.1

> LockImpl getLockToken missing scenario
> --------------------------------------
>
>                 Key: JCR-3946
>                 URL: https://issues.apache.org/jira/browse/JCR-3946
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.6.5, 2.10.1
>            Reporter: Flavel Heyman
>              Labels: LockImpl, locking, locks, session-scope
>
> Code in question for org.apache.jackrabbit.core.lock.LockImpl 
> {code:java}
>     public String getLockToken() {
>         if (!info.isSessionScoped() && (info.isLockHolder(node.getSession()) || isAdminUser(node.getSession()))) {
>             return info.getLockToken();
>         } else {
>             return null;
>         }
>     }
> {code}
> So if the a Non-Admin User (NAU) creates a lock and the session is not scoped, they are unable to retrieve the lock...which seems counter-intuitive since the lockholder is very much related to session instantiated in the first place.
> Shouldn't it be related more to session.getUserID()?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)