cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 27013] - [PATCH] fixed ContextSourceFactory
Date Thu, 19 Feb 2004 08:11:49 GMT
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 m_rolappe@web.de  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
{@link 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.

Mime
View raw message