DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27013>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27013 [PATCH] fixed ContextSourceFactory ------- Additional Comments From [EMAIL PROTECTED] 2004-02-19 08:11 ------- hi carsten, - it feels conceptually wrong to have a Source for context:/foo returning something other than 'context' for getScheme() and something other than 'context:/foo' for getURI() - the javadoc for Source.getScheme says '...This scheme can be used to get the [EMAIL PROTECTED] SourceFactory} responsible for this object...' - as the name 'context' implies the URI's path is relative to the context. the context may change (e.g. exploded vs. unexploded war). think of using the Source's URI as a stored reference to some resource used in a webapp; let's suppose we used an unexploded war and had 'context:/foo' resolve to a FileSource 'file:/home/webapps/myapp/foo'. then we would be in trouble later using that stored reference when we changed to e.g. be running from an unexploded war. the point is that the referenced resource's URI/location didn't change, but the context's base location changed and that the URI 'context:/foo' would still resolve correctly while the file source's wouldn't. - quoting myself '- although the source states otherwise the first '/' wouldn't be removed from the path...' I was referring to: ... // Remove the protocol and the first '/' final int pos = location.indexOf(":/"); final String path = location.substring(pos+1); ... which does not remove the first '/' but only the ':' - the patch also fixes bug #24093 more elegantly by checking whether the finally resolved location is within the context and at the same time allowing relative URIs to be used, instead of throwing a MalformedURLException - regarding the 'try file first, then resource': until I had the fix applied I didn't even have an error message in the logs from the entity resolver telling me that it couldn't find the catalogs (I didn't/don't use the entity resolver, though). but I think the Source should be fail-quick here; if the file referenced doesn't exist I see no point in returning a Source for it in the first place. not checking for the file's existence also precludes using a JAR's/WAR's resources; if I had the resource 'context:/foo' as a resource in my archive I possibly wouldn't be able to get it later on; if getRealPath() returns something != null a File is created and its URL resolved. the result of this is the returned 'context source'. but it's not checked whether the file exists and the resource isn't even tried. so what I get is a Source/reference to a file that may not exist, giving me a SourceNotFoundException later on, and being unable to use the possibly existing resource.
