[ 
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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to