From what I can see everything given in argument to the

A simpler option may just be to allow system properties as that would be much simpler to test. On Tue, 17 Sep 2019 at 10:45, Vincent Letarouilly < vincent.letarouilly(a)gmail.com&gt; wrote: > Hello everyone, > > I started some development on a closed ticket ( > https://issues.jboss.org/browse/KEYCLOAK-6990) in order to add the > ability > to load environment variables through theme.properties for custom themes. > I'd need some feedback from you to see if I'm taking the right path here > as > this is my first Keycloak dev and I'm not an expert in Java nor Maven. > This is what I've done so far > > https://github.com/Opa-/keycloak/commit/8f0517d17bd350d22d082516884a75788... > but > I'm quite unhappy with the duplication of the maven-surefire-plugin (you > can see that on top of my plugin block, there's an existing > maven-surefire-plugin plugin block) but I did not found other way to bring > an environment variable into the test context. > If someone could give me some feedback here it'd be very much appreciated > :) > > Regards, > Vincent > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

I didn't think about containers. You're right it makes it more awkward with containers. I guess env variables would be best, but would need to figure out how to test in that case. Maven wouldn't work as we are able to run tests from IDE as well with an embedded Keycloak server. Here's my suggestion. In theme.properties allow: value1=${my_system_property} value2=${env.MY_ENV_VALUE} Before loading theme properties create a new properties instance, load it with system properties as well as environment values (where env variables are prefixed with env.). In the theme.properties add properties for default env variables on different OS. Like so: linuxHome=${env.HOME} windowsHome=${env.HOMEPATH} Then you can check the properties with a runOnServer job rather than with a custom template. Something along the lines of (pseudo code, not functioning code): testingClient.server().run(session -> Theme t = ... if (System.getenv().containsKey("HOMEPATH")) assertEquals(System.getenv().get("HOMEPATH"), theme.getProperty("windowsHome")) else if .... ... else assert.fail("No default env variable found, can't verify")); See https://github.com/keycloak/keycloak/blob/master/testsuite/integration-ar... for more info On Tue, 17 Sep 2019 at 16:21, Vincent Letarouilly < vincent.letarouilly(a)gmail.com&gt; wrote: > Ok I got it working with system properties and it is indeed much simpler > to test ( > https://github.com/Opa-/keycloak/commit/0fce88947c99c2077827c2ca52514edc7... > ) > > However it is not clear to me how will I inject system properties when > running Keycloak inside the official docker container. > Do you know if I need to override the entrypoint and add some arguments ? > From what I can see everything given in argument to the > *docker-entrypoint.sh* will be passed to *standalone.sh* script and will > end up being passed to the java command with *$SERVER_OPTS* variable. > Is that correct or is there a simpler solution ? > > Best regards > > On Tue, Sep 17, 2019 at 11:15 AM Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> A simpler option may just be to allow system properties as that would be >> much simpler to test. >> >> On Tue, 17 Sep 2019 at 10:45, Vincent Letarouilly < >> vincent.letarouilly(a)gmail.com&gt; wrote: >> >>> Hello everyone, >>> >>> I started some development on a closed ticket ( >>> https://issues.jboss.org/browse/KEYCLOAK-6990) in order to add the >>> ability >>> to load environment variables through theme.properties for custom >>> themes. >>> I'd need some feedback from you to see if I'm taking the right path >>> here as >>> this is my first Keycloak dev and I'm not an expert in Java nor Maven. >>> This is what I've done so far >>> >>> https://github.com/Opa-/keycloak/commit/8f0517d17bd350d22d082516884a75788... >>> but >>> I'm quite unhappy with the duplication of the maven-surefire-plugin (you >>> can see that on top of my plugin block, there's an existing >>> maven-surefire-plugin plugin block) but I did not found other way to >>> bring >>> an environment variable into the test context. >>> If someone could give me some feedback here it'd be very much >>> appreciated :) >>> >>> Regards, >>> Vincent >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>