elmuerte commented on issue #71: VFS-444: corrected ResourceFileProvider uri/path processing. URL: https://github.com/apache/commons-vfs/pull/71#issuecomment-525694919 > Does this patch break existing call sites where String arguments that used to work now no longer work? Most of the tests in Vfs444TestCase are to cover this. As mentioned in the JIRA ticket, for some URIs the call to resolveURI() is successful, while the call to resolveFile() with the same URI produces an exception, or the other way around. In VFS 2.4.1 this would be the output: res:foo - resolveFullPathURI0 -> exception - resolveFullPathFile0 -> OK res:/foo - resolveFullPathURI1 -> OK - resolveFullPathFile1 -> exception res://foo - resolveFullPathURI2 -> OK - resolveFullPathFile2 -> exception With this patch the output is: res:foo - resolveFullPathURI0 -> OK - resolveFullPathFile0 -> OK res:/foo - resolveFullPathURI1 -> exception - resolveFullPathFile1 -> exception res:// - resolveFullPathURI2 -> exception - resolveFullPathFile2 -> exception So this will affect call sites depending on resolveURI(). In the new test ResSchemeTestCase suite the following tests fail (the rest passes, including test_resolveURI_String) - test_resolveURI_String_S - test_resolveURI_String_SS - test_resolveURI_String_SSS So you either have inconsistent behavior w.r.t. res: handling or, you need to break a call site. Should the following assertion hold? ```java FileName filename = VFS.getManager().resolveURI("res:/test.properties"); Assert.assertTrue(filename.isFile()); Assert.assertTrue(VFS.getManager().resolveFile(filename.getURI()).exists()); ``` i.e. should the uri accepted by resolveURI() also be accepted by resolveFile()? I've updated the ResSchemeTestCase with tests for these.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
