TCK Challenge: numConverterGetAsObjectLocaleTest uses improper format/locale combination

[brideck]

Challenged Tests:
com.sun.ts.tests.jsf.api.jakarta_faces.convert.numberconverter.URLClient#numConverterGetAsObjectLocaleTest

TCK Version:
Jakarta Faces 4.0.x

Tested Implementation:
Open Liberty -- containing MyFaces 4.0

Description:
This test is designed to "ensure getAsObject() picks up the Locale from the appropriate locations and uses it to create its value." However, it has the added (probably unintentional) wrinkle of testing with a mismatched combination of number format and locale, namely the French locale and the number 5.5. The French locale uses a comma delimiter for decimal numbers, so the proper number to use in this test would be 5,5. Because of this mismatch, the control case using java.text.NumberFormat ends up parsing 5.5 down to just 5 since it hits a character ('.') that is neither a digit nor a recognized delimiter.

In the 4.0 release, MyFaces added a quality-of-life improvement that flags this type of scenario, where an input string is not completely parsed, as an error. This results in this exception when running this test:

Caused by: jakarta.faces.convert.ConverterException: j_id__v_0: '5.5' nest pas un nombre.
    at jakarta.faces.convert.NumberConverter.getAsObject(NumberConverter.java:163)
    at com.sun.ts.tests.jsf.api.jakarta_faces.convert.numberconverter.TestServlet.numConverterGetAsObjectLocaleTest(TestServlet.java:384)

This test should be updated to use the proper format of 5,5. It would still be covering the stated design intention, and no longer inadvertently be testing a corner case where implementations may differ in how it is handled.