XML Partial-Response breaks with Currency Symbol on Wildfly/Primefaces

Question

I'm experiencing broken XML within a Request's response when it contains a currency symbol (in this case, '£').

I have done quite a bit of testing and have narrowed it down to the use of '£' in the XML that somehow causes an incomplete closing tag, which of course results in unparseable XML, e.g.:

<?xml version='1.0' encoding='UTF-8'?>
<partial-response>
<changes>
<update id="productForm">
<![CDATA[
<form enctype="application/x-www-form-urlencoded">
    <div>
         <span>
             <span id="productForm:price">£10.00</span>
         </span>
    </div>
</form>]]>
</update>
</changes>
</partial-response

This is due to the broken (not a typo) partial-response closing tag, as confirmed in the dev console:

The presence of the £ is the cause, as identified by debugging and testing.

Here's some assertions I can make:

• The affected code works fine on Java 7/Glassfish 3
• The same code does not work on Java 8/Wildfly 17 unless the £ sign is left out, at which point it is BAU

• The currency symbol has been attempted with:

  • <f:convertNumber type="currency" locale="en_GB" currencyCode="GBP"/>
  • <f:convertNumber type="currency" locale="en_GB" currencySymbol="&#163;"/> All of these fail.
  • <f:convertNumber type="currency" locale="en_GB" pattern="0.00"/> does not, but obviously because it doesn't end up with a £

• Deleting all the rest of the XHTML template and simply adding <p>&#163;</p> also makes it bork.

I can't see anything obvious that would be causing this - nor can I determine if it is an application server or application config issue. It has been tested on *NIX environments and there is nothing to suggest it is environmental in that regard.

Is there anything obvious I am missing here? All encoding I can see is set to UTF-8, so I'm stumped by this, and can find no other similar cases via searching.

Thanks for any suggestions in advance

Answer 1

After further investigation, this was found to be the (undetermined) result of a @WebFilter.

The web filter implementation intercepts certain values in the output string and, despite not actually changing the content of the request, especially in the debugger, this appeared to cause problems further into the response.

The problem area of the code in the web filter was:

servletResponse.setContentLength( filteredContent.length() );

I didn't write the class in question and suspect it might have been 'template code', but this re-setting of the attribute appears to cause far more problems than it solves. Removing it fixed the issue. It would appear that the servlet is capable of handling this attribute by itself (at least pending more testing).