Keycloak cannot run on windows machine in dev-mode. Because non-English systems cannot support keycloak's package's.

[tolga-karabudak]

Before reporting an issue

• [X] I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

dependencies

Describe the bug

When i change the system language problem solved. But I think that is not a proper solution.

Version

23.0.4

Expected behavior

To start a keycloak dev server.

Actual behavior

ERROR: No enum constant org.keycloak.common.Profile.ProfileValue.COMMUNİTY

COMMUNITY is not the package that keycloak's looking for.

How to Reproduce?

When i change system language in windows. Command Prompt's language changed and problem solved. But I think that's not a proper way.

Anything else?

Thank you for support.

[jonkoops]

This issue was reported for an older version of Keycloak, as per our policy stated in the issue template we only accept bug reports tested against the latest version. If this problem is reproducible in the latest version, feel free to log a new issue.

[tolga-karabudak]

I updated the version same problem accured.

[tolga-karabudak]

Also still, when I change system language to en-US it works properly but in Turkey, capital words are problem.

[jonkoops]

Thanks for testing that @tolga-karabudak, I'll re-open the issue.

[tolga-karabudak]

Thanks for fast response @jonkoops :)

[mposolda]

I consider this related to the distribution, so switching to cloud-native team for triage this.

[shawkins]

@tolga-karabudak I'm not sure where org.keycloak.common.Profile.ProfileValue is coming from - that doesn't match a known enum class. Nor is COMMUNITY an enum value that I recognize. Can you provide the full stack trace with using --verbose from a 23 release?

[stianst]

We had an enum ProfileValue a long time ago, but that has been removed, so I honestly can't see how this error message can be coming from the latest release.

[Pepo48]

@shawkins here's the stack trace: Notice that the enum is different in my case (it reflects to this enum), although I think I was able to reproduce the exact same error two weeks ago (as we already discussed offline). I suppose that the interpretation of the character "I" cause an issue.

What I quickly tried from a system level standpoint was to:

• change the CLI encoding
• set JAVA_OPTS=-Dfile.encoding=UTF8
• enable the "Beta: Use Unicode UTF-8 for worldwide language support" feature
• change the encoding of the batch script to UTF-8 with BOM

None of these helped.

Edit: I think that this may be the encoding on a system level related thing. This is how cygwin interprets it while trying to run Keycloak via kc.sh:

Edit2: After some research I found out that although the enums may differ in my and reporter's case, but the root cause should be the same - see the Reason: You’ve been hit with the “Turkish I” problem section.

[shawkins]

@Pepo48 oh, so it's not the reading of the values from the filesystem in this case, but the usage of toUpperCase - https://github.com/keycloak/keycloak/blob/b1a6a5a1b0e228e59d85a000240e39f13cd5446d/services/src/main/java/org/keycloak/theme/ClasspathThemeProviderFactory.java#L115 - the toUpperCase javadoc not coincidentally calls out Turkish.

It seems like we would have a lot places to check for things like upper/lower case, comparison/sorting, and any readers that may be using the system charset and could affect assumptions we're making. I know the profile logic at least does similar upper and lower conversions.

[Pepo48]

@shawkins correct, I already tried some quick fixes like Theme.Type type = Theme.Type.valueOf(t.toUpperCase(Locale.ENGLISH));, which made me able to surpass the point. But as you mentioned, it failed immediately at another place:

Caused by: java.util.concurrent.ExecutionException: org.infinispan.commons.CacheConfigurationException: ISPN000327: Cannot find a parser for element 'cache-container' in namespace 'urn:infinispan:config:14.0' at [25,41]. Check that your configuration is up-to-date for Infinispan '14.0.24.Final' and you have the proper dependency in the classpath
        at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205)
        at org.keycloak.quarkus.runtime.storage.legacy.infinispan.CacheManagerFactory.getOrCreate(CacheManagerFactory.java:72)

I'm debugging it further and trying to come up with something elegant, yet effective.

[vmuzikar]

I wonder if we should just set LC_ALL=en_US.UTF-8 in kc.sh|bat. There might be some side effects but I think local can be set on Realm level?

[Pepo48]

@vmuzikar I tried it but without the luck. I guess it's because LC_ALL=en_US.UTF-8 is unix-like notation. The Windows equivalent would the system setting I already tried and mentioned above:

enable the "Beta: Use Unicode UTF-8 for worldwide language support" feature

It changes the representation of the character compared to previous console output, but not in a desired way.

[Pepo48]

Guys, I was actually able to workaround it by setting the English locale on a JVM level:

I did the following:

chcp 65001 & cmd # to make sure I work with UTF-8 in an active console window, see the correctly displayed character this time
set "JAVA_OPTS=-Duser.language=en -Duser.country=US # to set the English locale via JVM options
kc.bat start-dev

(while the worldwide language support feature enabled on the system level)

@tolga-karabudak could you try the above mentioned in your environment?

cc: @shawkins @vmuzikar

[tolga-karabudak]

@Pepo48 Thanks for all of that! I'll try and comment my stack tree.

cc: @shawkins @vmuzikar

[tolga-karabudak]

Thanks!! @Pepo48 this workaround worked for me! I hope legal solution will release.

[vmuzikar]

@tolga-karabudak Thanks for the confirmation. Glad it works now.

@Pepo48 Re-opening as we probably want to include this in kc.sh/bat.

[vmuzikar]

Given the nature of the fix and a risk of regression, we won't be backporting this for now.