<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 January 2016 at 10:46, Marko Strukelj <span dir="ltr"><<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hot deployment is a tricky business always fraught with danger of<br>
leaving garbage behind, leading to difficult-to-explain slowdowns and<br>
eventually to out of memory, or to buggy behavior by not properly<br>
refreshing resources in all the places. By not using it we can save<br>
ourselves one possible cause for any such symptoms.<br></blockquote><div><br></div><div>Sure, but it's still nice to have if we could support it</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For production the proper way is to put it in a clustered setup of at<br>
least two instances. You can then restart one at a time. At least<br>
that's the idea.<br></blockquote><div><br></div><div>Actually that won't work, because the two nodes would have different themes for a period. Domain mode in WildFly supports deployments to a cluster, which would be much nicer if we supported that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For development there is a way to configure Keycloak to load themes<br>
from your source directory, you can then just refresh your browser to<br>
see changes.<br>
<br>
<br>
You can set that up like this:<br>
<br>
Build the project<br>
mvn clean install -DskipTests<br>
<br>
Open and edit distribution/server-dist/server-provisioning.xml<br>
Find copy-module-artifacts="true" and change it to copy-module-artifacts="false"<br>
<br>
I use:<br>
sed -i '' 's/copy-module-artifacts="true"/copy-module-artifacts="false"/'<br>
distribution/server-dist/server-provisioning.xml<br>
<br>
Then only build the server distribution module<br>
mvn clean install -Pdistribution -pl distribution/server-dist<br>
<br>
Finally instruct Keycloak to load themes from source directory. Open<br>
and edit distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json<br>
<br>
Find "dir": "${jboss.server.config.dir}/themes" and change it to<br>
"dir": "PATH_TO_YOUR_KEYCLOAK_GIT_HOME/forms/common-themes/src/main/resources/theme"<br>
<br>
I use:<br>
sed -i '' 's,"dir": "${jboss.server.config.dir}/themes","dir":<br>
"/Users/marko/devel/keycloak/keycloak/forms/common-themes/src/main/resources/theme",'<br>
distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I don't see the need for all those steps. All you need to do is change the dir property for the themes. Default built-in themes would then be loaded from the jars and your custom themes directly from the source.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On Mon, Jan 18, 2016 at 9:46 AM, Travis De Silva <<a href="mailto:traviskds@gmail.com">traviskds@gmail.com</a>> wrote:<br>
> I think the jar is a good idea. I have hocked it up with our Jenkins CI<br>
> process.<br>
><br>
> As you mentioned, since the themes are cached, we have no option but to<br>
> restart KeyCloak. This might go well in a non-clustered production<br>
> environment.<br>
><br>
> I don't think wildfly modules are reloadable. But wildfly allows you to<br>
> deploy a jar just like a war. Wondering why you guys didn't take that route<br>
> and went with the module route.<br>
><br>
> Also if there is anyway to clear the theme cache when we deploy a new change<br>
> without having to restart KeyCloak would be great. I don't want to disable<br>
> the cache settings in keycloak-server.json as cache is important for<br>
> performance but just want a way to reload it when we deploy new changes/new<br>
> themes via the jar file.<br>
><br>
><br>
> On Mon, 18 Jan 2016 at 19:25 Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>> wrote:<br>
>><br>
>> You can chuck it into standalone/configuration/themes for production as<br>
>> well. The docs suggest to not do that as in production you want a stable set<br>
>> of files and make sure all nodes in a cluster has the same versions. Themes<br>
>> are also by default cached, both on the server side and in the browser.<br>
>><br>
>> On 18 January 2016 at 08:59, Juraci Paixão Kröhling <<a href="mailto:juraci@kroehling.de">juraci@kroehling.de</a>><br>
>> wrote:<br>
>>><br>
>>> On 16.01.2016 23:29, Travis De Silva wrote:<br>
>>> > I don't think wildfly does hot deployment for modules.<br>
>>><br>
>>> How about adding/removing the module via the Wildfly CLI?<br>
>>><br>
>>> module add --name=the.theme... --resources=...jar<br>
>>><br>
>>> - Juca.<br>
>>> _______________________________________________<br>
>>> keycloak-user mailing list<br>
>>> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> keycloak-user mailing list<br>
>> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div></div>