[
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
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
> 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
