[
https://issues.apache.org/jira/browse/SOLR-13580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13580:
----------------------------
Attachment: SOLR-13580.patch
Status: Open (was: Open)
i've already submitted an openjdk ticket, will update this jira once public.
I'm attaching a patch for ParsingFieldUpdateProcessorsTest that:
* improves the test overall by changing all the {{assertTrue(v instanceOf X)}}
patterns to use {{org.hamcrest.core.IsInstanceOf}} so we get decent failure
messages in this type of situation
* adds an {{assumeThat}} to the affected test methods validating that
{{NumberFormat.getInstance(new Locale("fr","FR"));}} behaves as expected when
parsing a number with the french grouping seperator.
..i'll go ahead and commit ASAP to fix the 13-ea jenkins builds once precommit
passes.
> java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric
> UpdateProcessors when using the 'locale' config option
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-13580
> URL: https://issues.apache.org/jira/browse/SOLR-13580
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
> Labels: Java13
> Attachments: SOLR-13580.patch
>
>
> ParsingFieldUpdateProcessorsTest has uncovered a JDK 13-ea+26 bug when
> dealing with the fr_FR Locale (which may affect other locales as well) which
> causes the grouping seperator ( U+00A0 in fr_FR ) to be ignored when parsing,
> treating them as a termination character -- example: "10 898" is parsed as
> "10" instead of "10898", leaving the " 898" portion of the string unparsed.
> The way the ParseNumeric UpdateProcessors are implemented, the fact that the
> NumbertFormat instance does not recognize the entire string as a Number
> results in the String value being left "as is" in the input documents.
> In ParsingFieldUpdateProcessorsTest this has manifested as jenkins failures
> like this...
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ParsingFieldUpdateProcessorsTest
> -Dtests.method=testParseFloatNonRootLocale -Dtests.seed=AE6C840917DD963B
> -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=us -Dtests.timezone=GMT -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 0.03s |
> ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale <<<
> [junit4] > Throwable #1: java.lang.AssertionError
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([AE6C840917DD963B:B5B079D8B7786A26]:0)
> [junit4] > at
> org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at
> java.base/java.lang.reflect.Method.invoke(Method.java:567)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:830)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
