DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32886>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32886 Summary: client webdav lib doesn't return child collections using listwebdavresources Product: Slide Version: 2.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P2 Component: WebDAV client AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] I have a mature application working with client webdavlib 2.0, with the webdav server that comes with tomcat 5.0.28. Client webdavlib 2.1 seams to be broken. Method listWebdavResources() doesn't return child collections, but the parent collection itself. This is the directory structure I tested: parent/ child1/ child2/ file1.txt file2.txt This is my code: HttpURL url = new HttpURL("http://localhost:8080/webdav/[some-url]"); url.setUserinfo("user", "pass"); WebdavResource wdResource = new WebdavResource(url); WebdavResource[] webdavList = wdResource.listWebdavResources(); System.out.println("Display Name: " + wdResource.getDisplayName()); WebdavResource[] webdavList = null; webdavList = wdResource.listWebdavResources(); System.out.println("Children returned: " + webdavList.length); for (int idx = 0; idx < webdavList.length; idx++) { System.out.println("\t" + webdavList[idx].getDisplayName()); System.out.println("\t" + webdavList[idx].getHttpURL()); } This is the output: Display Name: parent Children returned: 3 file1.txt http://localhost:8080/webdav/parent/file1.txt child2 http://localhost:8080/webdav/parent/ file2.txt http://localhost:8080/webdav/parent/file2.txt The third result is the URL of the parent, with display name "child2"! So nothing about child1, although it comes from the server (see trace). And child2 URL is bad, because it shows parent URL. In general, I see that collection childs are never shown. And this is the http tracing I got. There are two requests involved, the first using depth 0 and the second using depth 1. FIRST REQUEST =============== PROPFIND /webdav/parent HTTP/1.1 Authorization: Basic anVncmVnbzE6cGFkZW50cm8= Content-Type: text/xml; charset=utf-8 User-Agent: Jakarta Commons-HttpClient/2.0final Host: localhost:8080 Content-Length: 207 Depth: 0 <?xml version="1.0" encoding="utf-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:displayname/> <D:getcontentlength/> <D:getcontenttype/> <D:resourcetype/> <D:getlastmodified/> <D:lockdiscovery/> </D:prop> </D:propfind> FIRST RESPONSE ================= HTTP/1.1 207 Multi-Estado Content-Type: text/xml;charset=UTF-8 Content-Length: 436 Date: Thu, 30 Dec 2004 09:51:45 GMT Server: Apache-Coyote/1.1 <?xml version="1.0" encoding="utf-8"?> <multistatus xmlns="DAV:"> <response> <href>/webdav/parent/</href> <propstat> <prop> <displayname><![CDATA[parent]]></displayname> <resourcetype> <collection/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <getcontentlength/> <getcontenttype/> <getlastmodified/> <lockdiscovery/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> </multistatus> SECOND REQUEST ================ PROPFIND /webdav/parent HTTP/1.1 Authorization: Basic anVncmVnbzE6cGFkZW50cm8= Content-Type: text/xml; charset=utf-8 User-Agent: Jakarta Commons-HttpClient/2.0final Host: localhost:8080 Content-Length: 207 Depth: 1 <?xml version="1.0" encoding="utf-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:displayname/> <D:getcontentlength/> <D:getcontenttype/> <D:resourcetype/> <D:getlastmodified/> <D:lockdiscovery/> </D:prop> </D:propfind> SECOND RESPONSE ================= HTTP/1.1 207 Multi-Estado Content-Type: text/xml;charset=UTF-8 Content-Length: 2028 Date: Thu, 30 Dec 2004 09:51:45 GMT Server: Apache-Coyote/1.1 <?xml version="1.0" encoding="utf-8"?> <multistatus xmlns="DAV:"> <response> <href>/webdav/parent/</href> <propstat> <prop> <displayname><![CDATA[parent]]></displayname> <resourcetype> <collection/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <getcontentlength/> <getcontenttype/> <getlastmodified/> <lockdiscovery/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/webdav/parent/file2.txt</href> <propstat> <prop> <displayname><![CDATA[file2.txt]]></displayname> <getcontentlength>10</getcontentlength> <getcontenttype>text/plain</getcontenttype> <resourcetype/> <getlastmodified>Mon, 27 Sep 2004 11:13:07 GMT</getlastmodified> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <lockdiscovery/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/webdav/parent/file1.txt</href> <propstat> <prop> <displayname><![CDATA[file1.txt]]></displayname> <getcontentlength>10</getcontentlength> <getcontenttype>text/plain</getcontenttype> <resourcetype/> <getlastmodified>Mon, 27 Sep 2004 11:13:07 GMT</getlastmodified> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <lockdiscovery/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/webdav/parent/child2/</href> <propstat> <prop> <displayname><![CDATA[child2]]></displayname> <resourcetype> <collection/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <getcontentlength/> <getcontenttype/> <getlastmodified/> <lockdiscovery/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/webdav/parent/child1/</href> <propstat> <prop> <displayname><![CDATA[child1]]></displayname> <resourcetype> <collection/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <getcontentlength/> <getcontenttype/> <getlastmodified/> <lockdiscovery/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> </multistatus> As you can see from the second response, all the resources are returned correctly from the server. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
