One note on this fix. It may not have originally been a bug. I saw this in 2.1M1 and changed it for my own use, but I guessed that the original writers had wanted to give users the ability to type in escaped URIs themselves. Eg. "/files/My%20File" instead of "/files/My File". I guess there are some cases where users have wanted to construct the escaped sequence themselves and not rely on the HTTPClient to escape it for them. Its great for me though as I use the client all the time and don't need to build my own escaped URIs :-)
Warwick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 27, 2004 7:23 AM To: [EMAIL PROTECTED] Subject: RE: Slide fixes to be reviewed 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
