You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org> on 2010/04/11 19:36:42 UTC
[jira] Closed: (XERCESC-1918) XInclude broken with multiple level
includes
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boris Kolpackov closed XERCESC-1918.
------------------------------------
Assignee: Boris Kolpackov
Resolution: Fixed
I have re-implemented the patch and committed it. Also fixed a few bugs and memory leaks in XInclude code while at it.
> XInclude broken with multiple level includes
> --------------------------------------------
>
> Key: XERCESC-1918
> URL: https://issues.apache.org/jira/browse/XERCESC-1918
> Project: Xerces-C++
> Issue Type: Bug
> Components: Non-Validating Parser
> Affects Versions: 3.0.0
> Environment: linux, windows
> Reporter: keith mcneill
> Assignee: Boris Kolpackov
> Fix For: 3.1.1, 3.2.0
>
> Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml, xinclude-middle.xml, xinclude-top.xml
>
>
> If you use xinclude on multiple levels (> 2) with relative path names. XInclude will break with an error something like "no scheme".
> I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude.
> When an includeDoc was found it created a DocumentFragment to hang the new copied nodes off of. At the end of processing it would paste the DocumentFragment on to the document. The problem was that DocumentFragment lost the absolute path in its getBaseURI(). This absolute path also contained the scheme.
> This diff fixes XInclude by not using a DocumentFragment. We just use insertBefore() to insert the new nodes in the destination document in order. This way the getBaseURI() is never lost.
> I've also included a fix to XIncludeLocation.prependPath(). PrependPath used to slam a new path on the beginning of the current path without checking to see if the current path already had a scheme. For example you could end up with paths like: file:///new/parent/file:///old/child. Now it will produce file:///new/parent/old/child. XIncludeLocation probably needs to get smarter about dealing with schemes & URI's in general.
> I've included a diff an example files that can be run with the XInclude sample.
> Note that with these fixes the xerces c++ xinclude behaves more like the java xinclude support.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org