Carsten Ziegeler wrote:
It seems that the problem is much worse than we imagined. I just found
out that our fix which corrects the url on macos has the problem that it
now creates a url which the jdk on macos can't understand anymore. So
the jdk seems to know the bug and expects this behaviour.
Note that the 'fixed' version breaks on all OS'es, whereas the
originally 'broken' version only broke the testcase on macos. This is
what i find very hard to grasp as the fix did not change anything for
the common 'non-macos' case right ? Also, the fix did not break the
existing sourceresolver tests, so it must have done something right...
Here is a snippet from Cocoon's directory generator:
String systemId = this.directorySource.getURI();
if (!systemId.startsWith(FILE)) {
throw new ResourceNotFoundException(systemId + " does
not denote a directory");
}
// This relies on systemId being of the form "file://..."
File directoryFile = new File(new URL(systemId).getFile());
if (!directoryFile.isDirectory()) {
throw new ResourceNotFoundException(super.source + " is
not a directory.");
}
With the correct 2.2.2 version, the last test fails as the file does not
point to the correct resource on the file system anymore. If we don't
fix the url and let getURI() return the wrong uri (with only one slash),
everything else works again.
I'm posting the unittest here that triggered all of this, so others can
chime in.
public void testURIHandling() throws Exception {
final String zipSourceUri = "zip:file://test.zip!/test.xml";
final String brokenMacOsXSourceUri = "zip:file:/test.zip!/test.xml";
Source zipSource;
SourceResolver resolver = null;
try {
resolver = (SourceResolver) getManager().lookup(SourceResolver.ROLE);
zipSource = resolver.resolveURI(zipSourceUri);
} catch (ServiceException se) {
throw new SourceException("SourceResolver is not available.", se);
} finally {
getManager().release(resolver);
}
assertTrue("Resolved Source is not an instance of ZipSource.",
zipSource instanceof ZipSource);
assertEquals("Scheme/protocol is wrong.", "zip", zipSource.getScheme());
String actualZipSourceUri = zipSource.getURI();
int index = actualZipSourceUri.indexOf("file://");
if (index != -1) {
assertEquals("Uri is wrong.", zipSourceUri, actualZipSourceUri);
} else {
// FIXME: special treatment for OS specific return value, should be
// removed after an update of Excalibur source resolve
// - https://issues.apache.org/jira/browse/COCOON-2022
// -
http://thread.gmane.org/gmane.comp.apache.excalibur.devel/2107
assertEquals("Uri is wrong.", brokenMacOsXSourceUri,
actualZipSourceUri);
}
}
> So, it seems that we should remove the url fix again and rely on the
> buggy implementation.
>
> WDYT?
I'm afraid yes, unless someone has a better idea :(
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
