[
https://issues.apache.org/jira/browse/VELTOOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699514#comment-17699514
]
steven van vlierberghe commented on VELTOOLS-197:
-------------------------------------------------
An explanation for the difference between XMmlTools 2.0 and XmlTools 3.1
can be found in the XmlTools.toString () method (that gets called when XPath
returns a NodeSet, to be converted to a String, eventually):
the 2.0 implementation is based on dom4j.Node.asXML()
whereas the 3.1 implementation is based XmlUtils.nodeToString(org.w3c.dom.Node)
Adding a call to org.apache.commons.lang3.StringEscapeUtils.unescapeXml on the
returned result would solve my problem in 3.1...
> 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-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
