[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-17379:
--------------------------------------
Attachment: SOLR-17379.test.patch
Status: Open (was: Open)
I'm attaching a patch that does a few things:
* adds assume logic to {{testAKSTZone}} to skip the test if we detect that the
current JVM's locale settings doesn't recognize that timezone string when
parsing the date
** No point in trying to test ParseDateFieldUpdateProcessorFactory with this
input if the JVM can't handle it
* improves the DEBUG logging from ParseDateFieldUpdateProcessorFactory when a
format throws a DateTimeParseException (to include the exception details)
* Tweaks ParsingFieldUpdateProcessorsTest to enable DEBUG logging from the
ParseDateFieldUpdateProcessorFactory
With these changes, using {{-Djava.locale.providers=CLDR}} on JDK21+ causes
{{testAKSTZone}} to be skipped, and {{testParseFrenchDate}} causes
{{ParseDateFieldUpdateProcessorFactory}} to log the details about _why_ it
doesn't parse the input, leading to the test failure...
{noformat}
2> 3731 DEBUG
(TEST-ParsingFieldUpdateProcessorsTest.testParseFrenchDate-seed#[47C458CCB37606F0])
[n: c: s: r: x: t:] o.a.s.u.p.ParseDateFieldUpdateProcessorFactory value 'le
vendredi 15 janvier 2010' is not parseable with format
'ParseStrict(false)ParseCaseSensitive(false)'le'' 'Text(DayOfWeek)'
'Value(DayOfMonth,2)' 'Text(MonthOfYear)' 'Value(YearOfEra,4,19,EXCEEDS_PAD)'
(using fr + UTC)
2> => java.time.format.DateTimeParseException: Text 'le vendredi 15
janvier 2010' could not be parsed at index 3
2> at
java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2108)
2> java.time.format.DateTimeParseException: Text 'le vendredi 15 janvier
2010' could not be parsed at index 3
2> at
java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2108)
~[?:?]
2> at
java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1978)
~[?:?]
2> at
org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.parseInstant(ParseDateFieldUpdateProcessorFactory.java:232)
~[main/:?]
2> at
org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.parsePossibleDate(ParseDateFieldUpdateProcessorFactory.java:186)
[main/:?]
{noformat}
...but i can't for the life of me understand _why_ the CLDR locale data doesn't
want to parse this string at the index (the day of the week).
It seems like it should, and when I did some adhoc manual testing with jshell
to try and reproduce the problem, it doesn't want to trigger the same exception
– so i'm convinced there is some nuance i'm missing (possibly due to an actual
bug in solr) ...
{noformat}
hossman@slate:~$ jshell --class-path
/home/hossman/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-lang3/3.15.0/21581109b4be710ea4b195d5760392ec284f9f11/commons-lang3-3.15.0.jar
-R -Djava.locale.providers=CLDR
| Welcome to JShell -- Version 21.0.2
| For an introduction type: /help intro
jshell> new
java.time.format.DateTimeFormatterBuilder().parseLenient().parseCaseInsensitive().appendPattern("'le'
EEEE dd MMMM
yyyy").toFormatter(org.apache.commons.lang3.LocaleUtils.toLocale("fr")).withResolverStyle(java.time.format.ResolverStyle.LENIENT).withZone(java.time.ZoneId.of("UTC")).parse("le
vendredi 15 janvier 2010", new java.text.ParsePosition(0));
$1 ==> {},ISO,UTC,-1 resolved to 2010-01-15
{noformat}
/ping [~uschindler] [~dsmiley]
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
> --------------------------------------------------------------------
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]