Well i couldn't wait, so i got my hands dirty, and started debugging the code. It was really easy to solve after all, the bug thas i was experiencing has nothing to do with WebdavResource. In org/apache/webdav/cmd/Client.java there's a method named "uriToHttpURL" that calls the commons library like this: "HttpURL(uri.toCharArray())". It turns out that if I use simply "HttpURL(uri)" it works as a breeze. So I guess i discoreved a bug in "public HttpURL(char[] chars)" in the commons library and discarded a futile function call. I will submit a bug, and a patch as soon as i get lunch :P
-----Original Message----- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 27 de Agosto de 2004 12:17 To: [EMAIL PROTECTED] Subject: Re: Slide fixes to be reviewed I'm pretty sure there's no bug related to spaces in pathnames in WebdavResource. But the commmand line client and the LockMethod may well have problems. I will have a look at the patches as soon as Warwick submits them. Ingo > Hi > I was having trouble with pathnames and spaces too, i'm designing an app, > and started by implementing the methods on top of the slide client, but some > didn't seem to work at all. > Later i associated the bad behaviour with the spaces in the filenames. > For instance, using the commandline client I'm getting this error when i try > to do some operations on a pathname that contains spaces: > > "[LOCALHOST:/slide/files/Folhas Soltas/] C:\ $ report tabacaria.txt > Getting version-tree Report of '/slide/files/Folhas Soltas/tabacaria.txt': > Error: escaped absolute path not valid" > > I suppose this is connected to the bug you refered in "WebdavResource.java"? > This error of course doesn't show up when there aren't any spaces in the > pathname. Do you think these patches will solve the problem? please submit > them quickly :) > > Thanks again > > -----Original Message----- > From: James Mason [mailto:[EMAIL PROTECTED] > Sent: sexta-feira, 27 de Agosto de 2004 7:39 > To: Slide Users Mailing List > Subject: Re: Slide fixes to be reviewed > > > Warwick, > Bugzilla is the best option for submitting fixes. It makes it easier to > track which fixes have been applied and which are pending. > > It's a bit of work, but if you can create a bug for each change you've > made that will be the easiest to keep track of. Otherwise just create a > single bug and attach all your changes and we'll keep track of what's > been done in the comments. > > Thanks for doing this, btw. I absolutely love it when someone submits a > bug *with* a patch :). > > -James > > Warwick Burrows wrote: > > Hi James, > > > > I actually have a number of fixes that I've made to get Slide working in > my > > configuration. I'd like to submit them all but would like to have them > > reviewed by a slide contributor first to make sure that they are ok. How > do > > I get them to the list as I haven't been able to send a zip or tar file > > attachment as they get bounced. > > > > Here's a summary of each change for context: > > > > > > WebdavResource.java: > > ------------------- > > - Found a problem establishing "existence" of paths with spaces in > > them. Eg. "My Files". The path coming back from the server was escaped and > > getPath() returns an unescaped string. Was failing to set existence as a > > result. Decode and compare the two on a common basis. > > - got a "wild-hare" about the the way a trailing '/' on one of the > > paths is dealt with so I changed it to make it a little faster and skips > > cases where the strings are definitely not equal regardless of the '/'. > > - added a lockMethod with a depth parameter to lock subdirs and > > their children. > > - added discoverOwnLocks with an owner parameter to get locks for a > > specific user and which is not the user in my client context (ie. no authn > > or authz is being used). > > > > > > LockMethod.java: > > ---------------- > > - similar to existence prob in WebdavResource.java for paths with > > spaces. The lock is stored in the hashmap by parseResponse with an escaped > > path. The check for existence of a lock on the resource uses an unescaped > > path so it wouldn't find the lock. I changed it to add the lock to the > > hashmap with the unescaped path so that its found. > > > > > > DOMUtils.java: > > -------------- > > - lock owner not being read out of response from server because > > owner value was "escaped" using CDATA decl. DOMUtils was only looking for > > text responses. > > > > > > Client.java: > > ------------ > > - couple of simple checks for null object refs. > > > > > > DB2RDBMSAdapter: > > ---------------- > > - check for null ref in case of empty result. > > - override CommonRDBMSAdapter version of > > convertRevisionNumberToComparable() with one using SQL functions supported > > by DB2. > > > > > > Thanks, > > Warwick > > > > > > -----Original Message----- > > From: James Mason [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 25, 2004 10:43 PM > > To: Slide Users Mailing List > > Subject: Re: lock owners not returned with lock properties in 2.1b1?? > > > > > > Warwick, > > Can you provide a patch for this? > > > > Thanks. > > -James > > > > Warwick Burrows wrote: > > > >>Looking for CDATA node types works. I just added it as an OR > >>condition. This problem may have arisen for me since we use numerical > >>owner codes and perhaps the server decided to wrap it in a CDATA > >>definition for that reason... I don't know. > >> > >>Warwick > >> > >> > >> > >>-----Original Message----- > >>From: Warwick Burrows [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, August 25, 2004 2:26 PM > >>To: 'Slide Users Mailing List' > >>Subject: RE: lock owners not returned with lock properties in 2.1b1?? > >> > >> > >> > >>I've tracked this down to the code that processes lockdiscovery > >>properties returned in the propfind. There is a call to > >>DOMUtils.getTextValue() in LockDiscoveryProperty.java and this call is > >>returning NULL instead of the CDATA that was returned by the server in > >>the D:owner element. Its because the code is checking whether the > >>element is a text node and only returning the value if it is. Since > >>the D:owner contains CDATA its not matching and returning a NULL result > > > > instead. > > > >>If anyone has already fixed this then let me know otherwise I'm going > >>to see whether changing getTextValue() to look for CDATA nodes as well > >>will fix it. > >> > >>Warwick > >> > >> > >> > >>-----Original Message----- > >>From: Warwick Burrows [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, August 25, 2004 10:30 AM > >>To: 'Slide User Group ([EMAIL PROTECTED])' > >>Subject: lock owners not returned with lock properties in 2.1b1?? > >> > >> > >>Hi, > >> > >>It seems that lock owners are not returned from the server with the > >>other lock information any more. I've seen this from the CLI and from > >>within my own application. I noticed it when the application that I > >>had working with 2.1M1 stopped working with 2.1B1. When I lock a > >>resource with an owner using "-o<name>" the command succeeds and a > >>locktoken comes back. But when I run "locks" on the object the owner > >>name is empty. Has anyone else seen this problem or can suggest why > >>this is happening? I'm running with security checking disabled but I > >>don't see why that would affect locking which is enabled. > >> > >>Thanks, > >>Warwick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] AVISO Esta mensagem e todos os seus anexos poder� conter informa��o confidencial para uso exclusivo do destinat�rio. Se a recebeu indevidamente, elimine-a por favor e informe o emissor. Obrigado. DISCLAIMER This e-mail and attachments may contain confidential information for exclusive use of its recipient. If you have received this e-mail in error, please delete it immediately and notify the sender. Thank You.
