Hi, I'm having a problem with locks in 2.1 M1 in that when I call the WebdavResource 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
