You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "steven van vlierberghe (Jira)" <de...@velocity.apache.org> on 2022/10/12 12:42:00 UTC
[jira] [Updated] (VELTOOLS-197) xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
[ https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
steven van vlierberghe updated VELTOOLS-197:
--------------------------------------------
Description:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
<input>
<rep>
<x>R&R</x>
<x>R&B</x>
</rep>
</input>
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText() for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
PS:
it can be solved in 3.1, by replacing $item2.find("./text()") by $item2.find("./text()").node().getNodeValue()
BUT
this really requires to adapt the script
the actual problem is that I give support in our software to users for running their own Velocity scripts in our software.
In the next version of our software, we upgraded Velocity + VelocityTools to 3.1
and as a consequence, scripts of the users might break;
meaning, this regression issue will impose our users to have to adapt their scripts that are used in production
and for sure, they will not be happy having to do so
was:
#foreach ($item2 in $xmlf1.find("/input/rep/x"))
xpath: ${item2.find("./text()")} xml: $item2.getText()
#end
with $xmlf1 an XmlTool instance initialized on the following inputfile:
{code:java}
<input>
<rep>
<x>R&R</x>
<x>R&B</x>
</rep>
</input>
{code}
using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText() for an xmlTool instance (and complying with the expectation)
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
However, using XmlTool 3.1, the xpath construct does not return the same as the getText,
so the xpath does not comply with expectation
{code:java}
xpath: R&R xml: R&R
xpath: R&B xml: R&B
{code}
> xmlTool.find("./text()") (XPATH) not the same as xmlTool.getText () (METHOD) when & in text
> -------------------------------------------------------------------------------------------
>
> Key: VELTOOLS-197
> URL: https://issues.apache.org/jira/browse/VELTOOLS-197
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
> Affects Versions: 3.1
> Reporter: steven van vlierberghe
> Priority: Major
>
> #foreach ($item2 in $xmlf1.find("/input/rep/x"))
> xpath: ${item2.find("./text()")} xml: $item2.getText()
> #end
> with $xmlf1 an XmlTool instance initialized on the following inputfile:
> {code:java}
> <input>
> <rep>
> <x>R&R</x>
> <x>R&B</x>
> </rep>
> </input>
> {code}
> using VeloctityTools-XmlTool 2.0 : find("./text()") returns same as getText() for an xmlTool instance (and complying with the expectation)
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
> However, using XmlTool 3.1, the xpath construct does not return the same as the getText,
> so the xpath does not comply with expectation
> {code:java}
> xpath: R&R xml: R&R
> xpath: R&B xml: R&B
> {code}
>
> PS:
> it can be solved in 3.1, by replacing $item2.find("./text()") by $item2.find("./text()").node().getNodeValue()
> BUT
> this really requires to adapt the script
> the actual problem is that I give support in our software to users for running their own Velocity scripts in our software.
> In the next version of our software, we upgraded Velocity + VelocityTools to 3.1
> and as a consequence, scripts of the users might break;
> meaning, this regression issue will impose our users to have to adapt their scripts that are used in production
> and for sure, they will not be happy having to do so
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org