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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user