[
https://issues.apache.org/jira/browse/SOLR-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-416.
----------------------------
Resolution: Not A Problem
Closing as not a problem. A full search of solr/core, solr/solrj, solr/api, and
solr/modules finds zero remaining no-arg .toUpperCase()/.toLowerCase() calls —
every call site now supplies an explicit Locale (mostly Locale.ROOT, some
Locale.ENGLISH). Beyond the one-time audit requested here, the build now
enforces this permanently via the forbidden-apis Gradle plugin's
jdk-non-portable bundled signature set
(gradle/validation/forbidden-apis.gradle), which fails the build on any future
locale-sensitive no-arg call.
Obviously if you disagree, please do reopen.
> need to audit all methods that might be using default Locale
> ------------------------------------------------------------
>
> Key: SOLR-416
> URL: https://issues.apache.org/jira/browse/SOLR-416
> Project: Solr
> Issue Type: Bug
> Reporter: Chris M. Hostetter
> Priority: Major
>
> As discussed on the mailing list, there are places in Solr where java methods
> that rely on the default locale are used to copare input with "constants" ...
> the specific use case that prompted this bug being string comparison after
> calling "toUpperCase()" ... this won't do what it should in some Locales...
> http://www.nabble.com/Invalid-value-%27explicit%27-for-echoParams-parameter-tf4837914.html
> we should audit the code as much as possible and try to replace these use
> cases in a way that will work for everyone....
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
