Hi,
I'm having a problem
with locks in 2.1M1 in that when I call the client lockMethod() using a URI
with spaces in it the lock command works but unlock won't. The reason seems to
be because within the parseResponse method of the LockMethod class the addLock
call is being made to add the lock to a hashmap. The key that is used is the
getPath() call for the LockMethod class which is inherited from the http commons
HttpMethodBase class. This getPath returns an escaped version of the path name.
But this path is only called in response to a lock response. There is also a
second call to addLock made after the response is parsed in the LockMethod
execute method. When this addLock is called it uses the getpath of the
WebdavResource which is the unescaped path -- but since the search for the lock
in the hashMap is made using the value (ie. the lock token) instead of the key
(the path name) the value that was set by the response parsing code is found and
the addLock just returns. But the unlock path doesn't parse a response
back from the server and so the call it makes to check if a lock exists for the
given key fails because unlockMethod uses the getPath of the WebdavResource
class and since this doesn't have %20 in there it fails because the lock token
entry was added with an escaped uri path from the HttpBaseMethod
class.
My guess is that
calling the HttpBaseMethod getPath call in parseResponse is the disconnect here
as the WebdavResource lockMethod and unlockMethods would be symmetrical to each
other under normal circumstances. So is it necessary to call addLock from the
LockMethod class parseResponse method when it seems that the WebdavResource
would normally add the lock itself when the LockMethod execute method has
completed successfully? If its necessary then why lock again in the
LockMethod execute method.
Thanks,
Warwick
|
| ||||
|
| ||||
|
|
|
Email:
[EMAIL PROTECTED] |
|
9600 Great Hills
Trail, #325 |
|
| ||||
