cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: XInclude Problem? -w- Patch
Date Wed, 15 Nov 2000 05:35:13 GMT
On Wed, 8 Nov 2000, Claude Warren wrote:

> I now beleive that there is a problem in
> org.apache.cocoon.processor.XIncludeProcessor$XincludeProcessorWorker.processXIncludeElement()
> in the block that reads:
>    } else if (xinclude.href.charAt(0) == '/') {
>     /** local absolute URI, e.g. /foo.xml **/
>     local = new File(Utils.getRootpath(request,context),xinclude.href);
>     system_id = ((File)local).getAbsolutePath();
>     content = new FileReader((File)local);
> Utils.getRootPath() returns a string of the form "/dir1/dir2"
> include.href is a string of the form "/dir3/dir4/file.xml"
> The File constructor attempts to put these together (as per the
> documentation) "/dir1/dir2"+"/"+"/dir3/dir4/file.xml"  resulting in the
> incorrect string "/dir1/dir2//dir3/dir4/file.xml".  At least that is
> what happens on my system.

hmm. two things:

1. that _is_ a valid path, at least in UNIX. extraneous slashes are

2. that is valid use of the File(String parent,String child) constructor:

Otherwise the parent pathname string is taken to denote a directory, and
the child pathname string is taken to denote either a directory or a
file. If the child pathname string is absolute then it is converted into a
relative pathname in a system-dependent way.

> My question is:  "Has anybody else encounterd this problem?"

don't think so.

> I believe the correct code should be:
>    } else if (xinclude.href.charAt(0) == '/') {
>     /** local absolute URI, e.g. /foo.xml **/
>     local = new File( Utils.getRootpath(request,context)+xinclude.href
> );
>     system_id = ((File)local).getAbsolutePath();
>     content = new FileReader((File)local);
> Note the "+" in the File constructor rather than the "," in the original
> implementation.

i think this is going to break for win32 users. god, i hate cross-platform
filesystem manipulation, especially when working on that fuzzy edge
between urlspace and filespace.

i'd ask you to try a different linux jvm and see if you get the same
behavior. my suspicion is that the ibm-1.1.8 jvm is broken in this regard.

- donald

View raw message