XInclude Problem? -w- Patch

[Claude Warren <cl...@histio.org>]

I am using Red Hat Linux 6.2, IBM jdk 1.1.8, and jserv.

I recently sent Robin a patch for the
org.apache.cocoon.Utils.getRootpath() to work with this configuration.
I hope that patch made its way to this list, if not I will post it.

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.

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

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.

Claude

Re: XInclude Problem? -w- Patch

[Donald Ball <ba...@webslingerZ.com>]

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
ignored.

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