[keycloak-user] Hotdeploy theme module

[Stian Thorgersen]

On 18 January 2016 at 13:52, Bill Burke <bburke at redhat.com> wrote:

> 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.
>

+1 To everything, but for 2.x


>
>
> On 1/18/2016 4:40 AM, Stian Thorgersen wrote:
>
>
>
> On 18 January 2016 at 09:46, Travis De Silva <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>
>> 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>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
>>>> 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
>>
>>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160118/f46ec4c9/attachment.html