[
https://issues.apache.org/jira/browse/SOLR-13580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875188#comment-16875188
]
ASF subversion and git services commented on SOLR-13580:
--------------------------------------------------------
Commit 881aabe28a0678d65074a6240ca976fcbfab27bf in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=881aabe ]
SOLR-13580: update test to account for different versions of java using
different locale specific numeric formatting characters
(cherry picked from commit 8b72e91df7b8ea545b6344d665bbb80e27a80aa4)
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
