You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (Resolved) (JIRA)" <ji...@apache.org> on 2012/01/12 19:39:39 UTC

[jira] [Resolved] (JCR-3205) Missing support for lock timeout and ownerHint in jcr-server

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

angela resolved JCR-3205.
-------------------------

       Resolution: Fixed
    Fix Version/s: 2.4

modified the DefaultItemCollection to use LockManager#lock instead of 
Node#lock and adjusted the webdav active-lock object accordingly.

since both features are defined to be optional by the jcr specification automated
testing would require quite some changes in the tck and the jcr2spi tests.
i did some quick verifications stepping into the OpenScopedLockTest and the
server was responding as expected with the fixes in place.

david, thanks for reporting this issue.
                
> Missing support for lock timeout and ownerHint in jcr-server
> ------------------------------------------------------------
>
>                 Key: JCR-3205
>                 URL: https://issues.apache.org/jira/browse/JCR-3205
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-server
>    Affects Versions: 2.3.6
>            Reporter: David Buchmann
>            Assignee: angela
>             Fix For: 2.4
>
>         Attachments: tcpdump.log
>
>
> trying to set the lock timeout when creating a lock seems not to work over the davex transport. the timeout is always 2147483.
> this was my test code:
> import javax.jcr.*;
> import javax.jcr.lock.*;
> import org.apache.jackrabbit.jcr2spi.RepositoryImpl;
> import org.apache.jackrabbit.jcr2spi.config.RepositoryConfig;
> String url = "http://localhost:8080/server/";
> String workspace = "tests";
> RepositoryConfig config = new RepositoryConfigImplTest(repoUrl);
> Repository repo = RepositoryImpl.create(config);
> Credentials sc = new SimpleCredentials("admin","admin".toCharArray());
> Session s = repo.login(sc,workspace);
> Node t;
> if (s.getRootNode().hasNode("test")) {
>     t = s.getRootNode().getNode("test");
> } else {
>     t = s.getRootNode().addNode("test", "nt:unstructured");
> }
> t.addMixin("mix:lockable");
> s.save();
> LockManager m = s.getWorkspace().getLockManager();
> Lock l = m.lock(t.getPath(), false, true, 10, "me");
> System.out.println(l.getSecondsRemaining());
> and the output is 2147483
> the relevant communication fragment is below, i attach the full trace in case i miss something.
> LOCK /server/tests/jcr%3aroot/test HTTP/1.1
> Timeout: Second-10
> Depth: 0
> Link: <urn:uuid0c740bb9-042a-4ef2-b019-1a6c52784c29>; rel="http://www.day.com/jcr/webdav/1.0/session-id"
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: Jakarta Commons-HttpClient/3.0
> Host: localhost:8080
> Content-Length: 254
> Content-Type: text/xml; charset=UTF-8
> <?xml version="1.0" encoding="UTF-8" standalone="no"?><D:lockinfo xmlns:D="DAV:"><D:lockscope><dcr:exclusive-session-scoped xmlns:dcr="http://www.day.com/jcr/webdav/1.0"/></D:lockscope><D:locktype><D:write/></D:locktype><D:owner>me</D:owner></D:lockinfo>
> HTTP/1.1 200 OK
> Content-Type: text/xml; charset=utf-8
> Content-Length: 450
> Lock-Token: <aa724c28-3c24-41e8-a3b4-9fc129adf732>
> Server: Jetty(6.1.x)
> <?xml version="1.0" encoding="UTF-8" standalone="no"?><D:prop xmlns:D="DAV:"><D:lockdiscovery><D:activelock><D:lockscope><dcr:exclusive-session-scoped xmlns:dcr="http://www.day.com/jcr/webdav/1.0"/></D:lockscope><D:locktype><D:write/></D:locktype><D:depth>0</D:depth><D:timeout>Second-2147483</D:timeout><D:owner>admin</D:owner><D:locktoken><D:href>aa724c28-3c24-41e8-a3b4-9fc129adf732</D:href></D:locktoken></D:activelock></D:lockdiscovery></D:prop>
> by the way: if i do not explicitly logout before the program exits, the lock is also not released even though it is session based. should the session not trigger a logout on destruction?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira