In that case, don't worry about it. I notice that one of you guys asked about test cases...I haven't had time to put them together, so I understand. And I'm only buried on the work front.
________________________________ From: Ralph Goers <[email protected]> To: Commons Users List <[email protected]> Sent: Fri, September 10, 2010 1:21:50 AM Subject: Re: [vfs] (trunk) webdav auth challenges not provided credentials I will do my best, but I have been overwhelmed between work and family issues recently. Ralph On Sep 8, 2010, at 1:33 PM, David Hausladen wrote: > I wonder if it'd be possible to get these two patches applied this week. I'd > really appreciate it if you'd at least look at them and provide a > disposition. > > > > > ________________________________ > From: David Hausladen <[email protected]> > To: Commons Users List <[email protected]> > Sent: Wed, September 8, 2010 4:09:27 PM > Subject: Re: [vfs] (trunk) webdav auth challenges not provided credentials > > NullPointerException: https://issues.apache.org/jira/browse/VFS-315 > Preemptive Auth: https://issues.apache.org/jira/browse/VFS-316 > > > > > > ________________________________ > From: David Hausladen <[email protected]> > To: Commons Users List <[email protected]> > Sent: Wed, September 8, 2010 12:20:20 PM > Subject: Re: [vfs] (trunk) webdav auth challenges not provided credentials > > Should anyone hit this post and be facing the same problem, I'll point out > what > > I found out to be the solution. I needed to use the > DefaultFileSystemManager.resolveFile(FileObject, String, FileSystemOptions) > method instead, which tunnels the options into the FileSystem. Otherwise, > you're out of luck. While it seems like the interface prohibits use by the > presence of the FileObject in the signature, you can leave it null and > provide >a > > > > URI string in the second parameter and provide the FileSystemOptions which > have > > been decorated with authentication information in the third. > > I'm also going to be sending some patches for some problems I encountered > while > > working with vfs. > 1. The default authentication approach seemed wasteful/inefficient enough to > call it a defect IMO. Expose a "preemptive" authentication option via > FileSystemOptions. > > 2. I found some NullPointerExceptions in the handling of the WebDAV >properties. > > > > > > I'll send the links to the issues once created. > > > > ________________________________ > From: David Hausladen <[email protected]> > To: Commons Users List <[email protected]> > Sent: Tue, September 7, 2010 1:00:59 PM > Subject: Re: [vfs] (trunk) webdav auth challenges not provided credentials > > I've been debugging it and it looks like the FileSystemOptions containing the > auth information aren't the same ones used to create the filesystem or look > up > properties of a FileObject. Is there any way to ensure that the instance of > FileSystemOptions one sets up using the *FileSystemConfigBuilders is the one > actually used by the file system operations? > > > > ----- Original Message ---- > From: dhauslad <[email protected]> > To: [email protected] > Sent: Thu, September 2, 2010 8:52:01 PM > Subject: [VFS] (trunk) webdav auth challenges not provided credentials > > > As long as the URI/path provided to the resolveFile-like methods contains the > user id and password, I've been successful getting stuff from webdav via the > VFS APIs. However, as soon as I start using some of the other methods on a > returned FileObject (for example: getContent().getAttributes()), I see this > kind of error in my log. > > 02 Sep 2010 15:43:25.937 DEBUG << "HTTP/1.1 401 Unauthorized[\r][\n]" > > I've tried setting up the UserAuthenticator on the > DefaultFileSystemConfigBuilder and the proxy authentication on the > WebdavFileSystemConfigBuilder to no avail. Where should I be supplying the > authentication information? > -- > View this message in context: >http://apache-commons.680414.n4.nabble.com/VFS-trunk-webdav-auth-challenges-not-provided-credentials-tp2524974p2524974.html >l > > > > > Sent from the Commons - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
