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 2023/01/11 12:07: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
PS2: also have the impression that plainly rendering $item2.find("./text()") as String also looses leading and trailing white space
PS: the actual reason for upgrading VelocityTools (2.0 > 3.1) is that VeraCode flags the 2.0-related velocity libraries having vulnerabilities (and also dependent libraries like common- beanutils); these vulnerabilities have been solved in 3.1.
Because there are (to us important) regression issues with upgrading the velocity stuff, we cannot upgrade and therefor remain stuck with flagged vulnerabilities in our software.
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}
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
PS2: also have the impression that plainly rendering $item2.find("./text()") as String also looses leading and trailing white space
> 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
>
> PS2: also have the impression that plainly rendering $item2.find("./text()") as String also looses leading and trailing white space
>
> PS: the actual reason for upgrading VelocityTools (2.0 > 3.1) is that VeraCode flags the 2.0-related velocity libraries having vulnerabilities (and also dependent libraries like common- beanutils); these vulnerabilities have been solved in 3.1.
> Because there are (to us important) regression issues with upgrading the velocity stuff, we cannot upgrade and therefor remain stuck with flagged vulnerabilities in our software.
--
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