>>I think you're going to be stuck with doing something like https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/ apache/solr/cloud/KerberosTestServices.java#L55 where there is a hard-coded list of locales that we know are broken.
@Mike - yes that's what I am doing currently. >>See the documentation for the java Locale class for what I mean, it is very thorough. https://docs.oracle.com/javase/8/docs/api/java/util/ Locale.html Thanks Robert. I will review the javadoc for better understanding. >>Yes but these are not bugs in what lucene is doing. >>These are bugs in third party software that completely break under certain Locales, because they don't know how to handle some newer locales (broken parsing and so on). Yes that seems to be case. But in this case, we are using Derby for unit testing only. In production deployments we would be using a standard RDBMS (e.g. mysql, postgres etc.). So I am wondering if we should provide a knob to suppress the randomization in such cases (just to avoid such issues with third-party software). e.g. we already have an annotation to suppress SSL (@SolrTestCaseJ4.SuppressSSL). May be we could do something similar for the Locale setting? To ensure that such setting is not abused inside lucene-solr repo, we can add it to the list of forbidden APIs. If this is acceptable, I will go ahead and create a jira. Thanks Hrishikesh On Fri, Oct 20, 2017 at 1:50 PM, Robert Muir <[email protected]> wrote: > Yes but these are not bugs in what lucene is doing. It is just setting > a random locale. > > These are bugs in third party software that completely break under > certain Locales, because they don't know how to handle some newer > locales (broken parsing and so on). Such code does not handle the fact > that Locales can be more than language + country + variant. Since Java > 1.7 they can also have script (seen in your example) and extensions > and support BCP 47. > > See the documentation for the java Locale class for what I mean, it is > very thorough. https://docs.oracle.com/javase/8/docs/api/java/util/ > Locale.html > > > On Fri, Oct 20, 2017 at 4:40 PM, Mike Drob <[email protected]> wrote: > > I think you're going to be stuck with doing something like > > https://github.com/apache/lucene-solr/blob/master/solr/ > core/src/test/org/apache/solr/cloud/KerberosTestServices.java#L55 > > where there is a hard-coded list of locales that we know are broken. > > > > On Fri, Oct 20, 2017 at 3:31 PM, Hrishikesh Gadre <[email protected]> > > wrote: > >> > >> Hi Dawid, > >> > >> Thanks for the feedback. > >> > >> Here is one failure scenario, > >> > >> Locale configured (via -Dtests.locale) -> sr-Latn > >> > >> The error message, > >> > >> ERROR XBM0X: Supplied locale description 'sr__#Latn' is invalid, > expecting > >> ln[_CO[_variant]] > >> > >> ln=lower-case two-letter ISO-639 language code, CO=upper-case two-letter > >> ISO-3166 country codes, see java.util.Locale. > >> > >> Note that if I use "sr-Latn-BA" instead, the test passes. My gut feeling > >> is that "sr-Latn" is not a valid locale string as it is not listed here, > >> http://www.oracle.com/technetwork/java/javase/java8locales-2095355.html > >> > >> > >> Another failure is > >> > >> Locale configured (via -Dtests.locale) -> und > >> > >> The error message is > >> > >> Supplied locale description '' is invalid, expecting ln[_CO[_variant]] > >> > >> ln=lower-case two-letter ISO-639 language code, CO=upper-case two-letter > >> ISO-3166 country codes, see java.util.Locale. > >> > >> For the time being, I am hard-coding these failure causing locales in > the > >> junit assume(...) so that I can skip the execution. But this is not > >> full-proof since there may be more locale configurations which may not > work > >> with Derby. So I wonder if there is any way to suppress this locale > >> randomization altogether? > >> > >> Thanks > >> Hrishikesh > >> > >> > >> > >> On Fri, Oct 20, 2017 at 12:39 PM, Dawid Weiss <[email protected]> > >> wrote: > >>> > >>> Only valid locales (for your Java) are selected, so this has to be an > >>> error. What failures do you see? Perhaps they should be reported to > >>> Derby? > >>> > >>> Dawid > >>> > >>> On Fri, Oct 20, 2017 at 8:14 PM, Hrishikesh Gadre < > [email protected]> > >>> wrote: > >>> > Hi, > >>> > > >>> > I am currently implementing solr authorization plugin backed by > Apache > >>> > Sentry. For the unit tests, I am using Solr test framework > >>> > (specifically > >>> > SolrCloudTestCase class). Occasionally I see unit test failures since > >>> > the > >>> > sentry tests use Derby in-memory database and it doesn't work > properly > >>> > for > >>> > some of the Locale(s) configured by the Solr test framework. > >>> > > >>> > Couple of questions > >>> > > >>> > (a) Does the Solr test framework generates only valid Locale(s) or a > >>> > mix of > >>> > valid/invalid Locale(s) ? The reason I am asking is that I have a > test > >>> > failure with Locale as "sr-Latn". But it is not included in the list > of > >>> > valid Locales supported by Java 8 > >>> > > >>> > (http://www.oracle.com/technetwork/java/javase/ > java8locales-2095355.html). > >>> > > >>> > (b) Is there a way to turn off this Locale randomization? > >>> > > >>> > > >>> > Thanks > >>> > Hrishikesh > >>> > > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
