Parameter values are converted to lowercase when passed on the command line

[AndyGee]

Command line prameter is "--targetLocale=zh_TW" (Mixed case value)

@option("targetLocale") final Locale targetLocale //Preferred method
@option("targetLocale") final String targetLocale //Tested, but same result

Either option produces a lowercase value "zh_tw" - So the command line parameter case is NOT honoured.

Locale z = new Locale("zh_zw"); is not validated, but is also NOT a valid locale.
org.apache.commons.lang3.LocaleUtils.toLocale(z.toString()); is validated and throws an error.

The command and value case must not be converted to lowercase.

[rmannibucau]

Hi @AndyGee ,

I don't think it is crest by itself, typically the second flavor (using a String) passthrough the case.
The issue with the Locale is the usage of Locale(String) implicitly because there is no property editor of String->Locale and this constructors does not parse the locale properly (this is the one doing the tolowercase).

Typically this test passes:

public class SampleTest {
    @Test
    public void run() throws Exception {
        PropertyEditorManager.registerEditor(Locale.class, LocaleEditor.class);
        assertEquals(
                "zh_TW/zh_TW",
                new Main(Commands.class).exec("locales", "--locale=zh_TW", "--locale-string=zh_TW"));
    }

    public static class Commands {
        @Command
        public String locales(@Option("locale") final Locale locale,
                              @Option("locale-string") final String localeString) {
            return locale.toString() + "/" + localeString;
        }
    }

    public static class LocaleEditor extends PropertyEditorSupport {
        @Override
        public void setAsText(final String s) {
            final String[] segments = s.split("_");
            switch (segments.length) {
                case 1:
                    setValue(new Locale(s));
                    break;
                case 2:
                    setValue(new Locale(segments[0], segments[1]));
                    break;
                case 3:
                    setValue(new Locale(segments[0], segments[1], segments[2]));
                    break;
                default:
                    throw new IllegalArgumentException(s);
            }
        }
    }
}

[AndyGee]

The issue is from the command line. Embedded tests won't pick it up. You'll need to build the jar and execute it. That's what caught me out. On 3 Feb 2020 12:51, Romain Manni-Bucau <[email protected]> wrote:Hi @AndyGee , I don't think it is crest by itself, typically the second flavor (using a String) passthrough the case. The issue with the Locale is the usage of Locale(String) implicitly because there is no property editor of String->Locale and this constructors does not parse the locale properly (this is the one doing the tolowercase). Typically this test passes: public class SampleTest { @test public void run() throws Exception { PropertyEditorManager.registerEditor(Locale.class, LocaleEditor.class); assertEquals( "zh_TW/zh_TW", new Main(Commands.class).exec("locales", "--locale=zh_TW", "--locale-string=zh_TW")); } public static class Commands { @command public String locales(@option("locale") final Locale locale, @option("locale-string") final String localeString) { return locale.toString() + "/" + localeString; } } public static class LocaleEditor extends PropertyEditorSupport { @OverRide public void setAsText(final String s) { final String[] segments = s.split("_"); switch (segments.length) { case 1: setValue(new Locale(s)); break; case 2: setValue(new Locale(segments[0], segments[1])); break; case 3: setValue(new Locale(segments[0], segments[1], segments[2])); break; default: throw new IllegalArgumentException(s); } } } } —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[AndyGee]

Just do a print of the parameter value in the command, build the jar. The run it. Same issue on win and mac On 3 Feb 2020 14:29, [email protected] wrote:The issue is from the command line. Embedded tests won't pick it up. You'll need to build the jar and execute it. That's what caught me out. On 3 Feb 2020 12:51, Romain Manni-Bucau <[email protected]> wrote:Hi @AndyGee , I don't think it is crest by itself, typically the second flavor (using a String) passthrough the case. The issue with the Locale is the usage of Locale(String) implicitly because there is no property editor of String->Locale and this constructors does not parse the locale properly (this is the one doing the tolowercase). Typically this test passes: public class SampleTest { @test public void run() throws Exception { PropertyEditorManager.registerEditor(Locale.class, LocaleEditor.class); assertEquals( "zh_TW/zh_TW", new Main(Commands.class).exec("locales", "--locale=zh_TW", "--locale-string=zh_TW")); } public static class Commands { @command public String locales(@option("locale") final Locale locale, @option("locale-string") final String localeString) { return locale.toString() + "/" + localeString; } } public static class LocaleEditor extends PropertyEditorSupport { @OverRide public void setAsText(final String s) { final String[] segments = s.split("_"); switch (segments.length) { case 1: setValue(new Locale(s)); break; case 2: setValue(new Locale(segments[0], segments[1])); break; case 3: setValue(new Locale(segments[0], segments[1], segments[2])); break; default: throw new IllegalArgumentException(s); } } } } —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[rmannibucau]

Hmm, it behaves exactly the same for me. The only difference is you can't register the editor as in the test and must register it before the command parameters are instantiated.
You can either wrap the crest main to do that or use its Loader API (with its META-INF/services/org.tomitribe.crest.cmds.processors.Commands$Loader) if it is how you register commands:

public class Registrar implements Commands.Loader {
    @Override
    public Iterator<Class<?>> iterator() {
        PropertyEditorManager.registerEditor(Locale.class, LocaleEditor.class);
        return Collections.<Class<?>>singleton(LocaleCmd.class).iterator();
    }
}

[AndyGee]

I'm not so worried about the Locale as I am about the String, that's the one that surprises me. It makes a workaround even more difficult. I'll check the code out at the weekend and attach a debugger to the jar execution. On 3 Feb 2020 16:08, Romain Manni-Bucau <[email protected]> wrote:Hmm, it behaves exactly the same for me. The only difference is you can't register the editor as in the test and must register it before the command parameters are instantiated. You can either wrap the crest main to do that or use its Loader API (with its META-INF/services/org.tomitribe.crest.cmds.processors.Commands$Loader) if it is how you register commands: public class Registrar implements Commands.Loader { @OverRide public Iterator<Class<?>> iterator() { PropertyEditorManager.registerEditor(Locale.class, LocaleEditor.class); return Collections.<Class<?>>singleton(LocaleCmd.class).iterator(); } } —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[AndyGee]

Thanks for confirming though. On 4 Feb 2020 06:30, [email protected] wrote:I'm not so worried about the Locale as I am about the String, that's the one that surprises me. It makes a workaround even more difficult. I'll check the code out at the weekend and attach a debugger to the jar execution. On 3 Feb 2020 16:08, Romain Manni-Bucau <[email protected]> wrote:Hmm, it behaves exactly the same for me. The only difference is you can't register the editor as in the test and must register it before the command parameters are instantiated. You can either wrap the crest main to do that or use its Loader API (with its META-INF/services/org.tomitribe.crest.cmds.processors.Commands$Loader) if it is how you register commands: public class Registrar implements Commands.Loader { @OverRide public Iterator<Class<?>> iterator() { PropertyEditorManager.registerEditor(Locale.class, LocaleEditor.class); return Collections.<Class<?>>singleton(LocaleCmd.class).iterator(); } } —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.