hi roland
as far as i know, the <locktoken> element is present
in the lock-discovery property if the jcr-session
that has been attached to the request is the lock-holder.
otherwise it's omitted. this is mainly due to the nature
of the the JCR-Lock that is created by default:
the JCR Lock object only reveals the lock token if the
Session that obtained the lock from the node is the
lock-holder.
and for me it makes sense to propage the webDAV lock
into the repository instead of keeping them in the
webdav-layer (means: there is no lock on the repository
level).
what do you think?
angela
Roland Porath wrote:
Hi Angela and Julian,
Tried to send the following message but the spam filter did not like it so I
thought I'd forward it to you personally;
Cheers
roland
-----Original Message-----
From: Roland Porath [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 30 January 2008 4:57 PM
To: '[email protected]'
Subject: RE: problems with lock-depth infinity
I think I've isolated the problem.
The depth property was just a red herring.
I'll try to describe it as best as I can; it is a bit confusing and long
winded
1) create a file
2) lock that file
3) propget <some_resource> lockdiscovery
returns something like
lockdiscovery =
<activelock>
<lockscope>
<exclusive></exclusive>
</lockscope>
<locktype>
<write></write>
</locktype>
<depth>infinity</depth>
<timeout>Second-2147483</timeout>
<owner>Administrator</owner>
</activelock>
if I do the same thing in slide the lockdiscovery looks a bit different:
<activelock>
<locktype>
<write></write>
</locktype>
<lockscope>
<exclusive></exclusive>
</lockscope>
<depth>0</depth>
<owner>
<href>mailto:[EMAIL PROTECTED]</href>
</owner>
<timeout>Infinite</timeout>
<locktoken>
<href>opaquelocktoken:a2ad0e60e3b90b13795f418558872dd2</href>
</locktoken>
</activelock>
The major difference seems to be the <locktoken> element
My theory now is that some clients (i.e cadaver) do some caching and
remember the locktokens of the resources that were locked by themselves.
This is consistent with behavior i have observed so far:
Dav Explorer: can lock, can't unlock anything (=> no caching)
Cadaver: can lock, can unlock files that i locked in the same session (=>
transient caching)
WebFolders: only kidding.
The Lock request looks like this
LOCK
/jackrabbit-webapp-1.4/repository/default/SmartRepository/files/Demonstratio
n/locktest/asdf.txt HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: cadaver/0.22.2 neon/0.24.6
Connection: TE
TE: trailers
Content-Length: 203
Content-Type: application/xml
Depth: infinity
Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLkRPTQ==
<?xml version="1.0" encoding="utf-8"?>
<lockinfo xmlns='DAV:'>
<lockscope><exclusive/></lockscope>
<locktype><write/></locktype><owner><href>mailto:[EMAIL PROTECTED]</href
</owner>
</lockinfo>
It generates this response:
HTTP/1.1 200 OK
Lock-Token: <6332dc3f-df44-44a5-adbb-980c7edd3c8c-D>
Content-Type: text/xml;charset=UTF-8
Content-Length: 389
Date: Wed, 30 Jan 2008 05:13:53 GMT
Server: Apache-Coyote/1.1
<?xml version="1.0" encoding="UTF-8"?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:lockscope>
<D:exclusive/>
</D:lockscope>
<D:locktype>
<D:write/>
</D:locktype>
<D:depth>infinity
</D:depth>
<D:timeout>Second-2147483
</D:timeout>
<D:owner>Administrator
</D:owner>
<D:locktoken>
<D:href>6332dc3f-df44-44a5-adbb-980c7edd3c8c-D
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
so it seems like the token gets generated but not added to the lookdiscovery
propery
Is it possible to change that behavior??
cheers
roland
