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 "keith mcneill (JIRA)" <xe...@xml.apache.org> on 2010/03/31 19:15:27 UTC
[jira] Created: (XERCESC-1918) XInclude broken with multiple level
includes
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
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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1918) XInclude broken with multiple
level includes
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852089#action_12852089 ]
Boris Kolpackov commented on XERCESC-1918:
------------------------------------------
Keith, thanks for the patch. I would like to commit it, however, the project's charter[1] requires me to get the answers to the following questions from you before I can do this:
a) Name and employer
b) Are you the author of the code being contributed?
c) Do you have the right to grant the copyright and patent licenses for the contribution that are set forth in the ASF v.2.0 license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have written, for example, through your contract for employment? If so, has your employer given you permission to contribute the code on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other restrictions (such as related patents or trademarks) that could apply to your contribution? If so, what are they?
If you can provide the answers as a comment for this issue, that would be great.
[1] http://xerces.apache.org/xerces-c/charter.html
> 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
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Updated: (XERCESC-1918) XInclude broken with multiple level
includes
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boris Kolpackov updated XERCESC-1918:
-------------------------------------
Fix Version/s: 3.1.1
3.2.0
Scheduling for 3.1.1.
> 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
> 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
[jira] Updated: (XERCESC-1918) XInclude broken with multiple level
includes
Posted by "keith mcneill (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
keith mcneill updated XERCESC-1918:
-----------------------------------
Attachment: xerces-c-xinclude.diff
> 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
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Updated: (XERCESC-1918) XInclude broken with multiple level
includes
Posted by "keith mcneill (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
keith mcneill updated XERCESC-1918:
-----------------------------------
Attachment: xinclude-bottom.xml
> 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
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Updated: (XERCESC-1918) XInclude broken with multiple level
includes
Posted by "keith mcneill (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
keith mcneill updated XERCESC-1918:
-----------------------------------
Attachment: xinclude-top.xml
xinclude-middle.xml
> 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
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Closed: (XERCESC-1918) XInclude broken with multiple level
includes
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ 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