[keycloak-user] Hotdeploy theme module

[Bill Burke]

I think we should support this.  We also need to make sure deploying 
these components also picks up things like EJBs, JPA, etc.  For 2.0 we 
should probably consider using JTA too.

On 1/18/2016 4:40 AM, Stian Thorgersen wrote:
>
>
> On 18 January 2016 at 09:46, Travis De Silva <traviskds at gmail.com 
> <mailto:traviskds at gmail.com>> wrote:
>
>     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.
>
>
> The ideal would be to be able to hot-deploy both themes and providers, 
> but using modules is much easier. We could probably extend the 
> Keycloak subsystem to detect deployment of theme jars as they contain 
> a keycloak-themes.json. Provider jars would be slightly harder unless 
> we add some marker file.
>
> For themes you would have to clear the theme cache. Again, this is 
> something the subsystem could probably do and it could automatically 
> clear the cache for the themes found in the deployed theme jar. To 
> prevent browser caches we'd also need some mechanism to do that. 
> Currently resources are versioned by the version of the server and 
> that's it. So if you change a resource it wouldn't be updated in the 
> users browser.
>
> All nice to haves, but we don't have the resources ATM to implement it.
>
>
>
>     On Mon, 18 Jan 2016 at 19:25 Stian Thorgersen <sthorger at redhat.com
>     <mailto:sthorger at 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 at kroehling.de <mailto:juraci at 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 at lists.jboss.org
>             <mailto:keycloak-user at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160118/52c55d48/attachment.html