I think the jar is a good idea. I have hocked it up with our Jenkins CI process. 

As you mentioned, since the themes are cached, we have no option but to restart KeyCloak. This might go well in a non-clustered production environment.

I don't think wildfly modules are reloadable. But wildfly allows you to deploy a jar just like a war. Wondering why you guys didn't take that route and went with the module route. 

Also if there is anyway to clear the theme cache when we deploy a new change without having to restart KeyCloak would be great. I don't want to disable the cache settings in keycloak-server.json as cache is important for performance but just want a way to reload it when we deploy new changes/new themes via the jar file.


On Mon, 18 Jan 2016 at 19:25 Stian Thorgersen <sthorger@redhat.com> wrote:
You can chuck it into standalone/configuration/themes for production as well. The docs suggest to not do that as in production you want a stable set of files and make sure all nodes in a cluster has the same versions. Themes are also by default cached, both on the server side and in the browser.

On 18 January 2016 at 08:59, Juraci Paixão Kröhling <juraci@kroehling.de> wrote:
On 16.01.2016 23:29, Travis De Silva wrote:
> I don't think wildfly does hot deployment for modules.

How about adding/removing the module via the Wildfly CLI?

module add --name=the.theme... --resources=...jar

- Juca.
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user