7:11 a.m.
Hi,
As the the KeyCloak docs (
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html...
)
You can bundle a theme into a jar and deploy it as a wildfly module.
This all works fine but the module is not hotdeployable. Whenever you do
changes, you need to remove the module, then add it again and restart
KeyCloak.
As you can imagine this is not ideal.
I trying to deploy the jar as a normal deployment as in Wildfly you can
deploy jar file like you do war files.
When you deploy like this, the module name is deployment.javafilename.jar
Then I added this name to the keycloak-server.json file but when I restart
KeyCloak, it is not identifying the module.
Is there any other war where I can get my themes to reload once I redeploy
the jar?
Note that as per the Keyclok docs, I disabled theme cache as well.
Cheers
Travis
8:42 a.m.
Isn't there a theme directory in standalone/configuration? I don't know
if it is rechecked or not.
On 1/16/2016 8:11 AM, Travis De Silva wrote:
Hi,
As the the KeyCloak docs
(http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html...)
You can bundle a theme into a jar and deploy it as a wildfly module.
This all works fine but the module is not hotdeployable. Whenever you
do changes, you need to remove the module, then add it again and
restart KeyCloak.
As you can imagine this is not ideal.
I trying to deploy the jar as a normal deployment as in Wildfly you
can deploy jar file like you do war files.
When you deploy like this, the module name is deployment.javafilename.jar
Then I added this name to the keycloak-server.json file but when I
restart KeyCloak, it is not identifying the module.
Is there any other war where I can get my themes to reload once I
redeploy the jar?
Note that as per the Keyclok docs, I disabled theme cache as well.
Cheers
Travis
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:29 p.m.
yes but the keycloak docs indicate that for production instances, to bundle
the custom theme into a jar and then deploy it as a module.
The hot deployment does not work when you deploy it as a module as
indicated in the keycloak docs.
I don't think wildfly does hot deployment for modules. But wildfly also
mentions that everything that is deployed such as war files, jar files are
modules. Therefore instead of creating the standard wildfly module, I tried
to deploy it as a standard jar deployment and then referred to that
deployment name in keycloak-server.json but keycloak did not pick it up.
On Sun, 17 Jan 2016 at 01:43 Bill Burke <bburke(a)redhat.com> wrote:
Isn't there a theme directory in standalone/configuration? I
don't know
if it is rechecked or not.
On 1/16/2016 8:11 AM, Travis De Silva wrote:
Hi,
As the the KeyCloak docs (
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html...
)
You can bundle a theme into a jar and deploy it as a wildfly module.
This all works fine but the module is not hotdeployable. Whenever you do
changes, you need to remove the module, then add it again and restart
KeyCloak.
As you can imagine this is not ideal.
I trying to deploy the jar as a normal deployment as in Wildfly you can
deploy jar file like you do war files.
When you deploy like this, the module name is deployment.javafilename.jar
Then I added this name to the keycloak-server.json file but when I restart
KeyCloak, it is not identifying the module.
Is there any other war where I can get my themes to reload once I redeploy
the jar?
Note that as per the Keyclok docs, I disabled theme cache as well.
Cheers
Travis
_______________________________________________
keycloak-user mailing
listkeycloak-user@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:24 a.m.
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
2:46 a.m.
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
3:40 a.m.
On 18 January 2016 at 09:46, Travis De Silva <traviskds(a)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(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
6:52 a.m.
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(a)gmail.com
<mailto:traviskds@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(a)redhat.com
<mailto: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(a)kroehling.de <mailto: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(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:35 a.m.
On 18 January 2016 at 13:52, Bill Burke <bburke(a)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(a)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(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@kroehling.de>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
>
>
_______________________________________________
keycloak-user mailing
listkeycloak-user@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:46 a.m.
Hot deployment is a tricky business always fraught with danger of
leaving garbage behind, leading to difficult-to-explain slowdowns and
eventually to out of memory, or to buggy behavior by not properly
refreshing resources in all the places. By not using it we can save
ourselves one possible cause for any such symptoms.
For production the proper way is to put it in a clustered setup of at
least two instances. You can then restart one at a time. At least
that's the idea.
For development there is a way to configure Keycloak to load themes
from your source directory, you can then just refresh your browser to
see changes.
You can set that up like this:
Build the project
mvn clean install -DskipTests
Open and edit distribution/server-dist/server-provisioning.xml
Find copy-module-artifacts="true" and change it to
copy-module-artifacts="false"
I use:
sed -i ''
's/copy-module-artifacts="true"/copy-module-artifacts="false"/'
distribution/server-dist/server-provisioning.xml
Then only build the server distribution module
mvn clean install -Pdistribution -pl distribution/server-dist
Finally instruct Keycloak to load themes from source directory. Open
and edit
distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json
Find "dir": "${jboss.server.config.dir}/themes" and change it to
"dir":
"PATH_TO_YOUR_KEYCLOAK_GIT_HOME/forms/common-themes/src/main/resources/theme"
I use:
sed -i '' 's,"dir":
"${jboss.server.config.dir}/themes","dir":
"/Users/marko/devel/keycloak/keycloak/forms/common-themes/src/main/resources/theme",'
distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json
On Mon, Jan 18, 2016 at 9:46 AM, Travis De Silva <traviskds(a)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.
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
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:01 a.m.
On 18 January 2016 at 10:46, Marko Strukelj <mstrukel(a)redhat.com> wrote:
Hot deployment is a tricky business always fraught with danger of
leaving garbage behind, leading to difficult-to-explain slowdowns and
eventually to out of memory, or to buggy behavior by not properly
refreshing resources in all the places. By not using it we can save
ourselves one possible cause for any such symptoms.
Sure, but it's still nice to have if we could support it
For production the proper way is to put it in a clustered setup of at
least two instances. You can then restart one at a time. At least
that's the idea.
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.
For development there is a way to configure Keycloak to load themes
from your source directory, you can then just refresh your browser to
see changes.
You can set that up like this:
Build the project
mvn clean install -DskipTests
Open and edit distribution/server-dist/server-provisioning.xml
Find copy-module-artifacts="true" and change it to
copy-module-artifacts="false"
I use:
sed -i ''
's/copy-module-artifacts="true"/copy-module-artifacts="false"/'
distribution/server-dist/server-provisioning.xml
Then only build the server distribution module
mvn clean install -Pdistribution -pl distribution/server-dist
Finally instruct Keycloak to load themes from source directory. Open
and edit
distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json
Find "dir": "${jboss.server.config.dir}/themes" and change it to
"dir":
"PATH_TO_YOUR_KEYCLOAK_GIT_HOME/forms/common-themes/src/main/resources/theme"
I use:
sed -i '' 's,"dir":
"${jboss.server.config.dir}/themes","dir":
"/Users/marko/devel/keycloak/keycloak/forms/common-themes/src/main/resources/theme",'
distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json
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.
On Mon, Jan 18, 2016 at 9:46 AM, Travis De Silva
<traviskds(a)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.
>
>
> 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
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
4:48 a.m.
On Mon, Jan 18, 2016 at 11:01 AM, Stian Thorgersen <sthorger(a)redhat.com> wrote:
On 18 January 2016 at 10:46, Marko Strukelj <mstrukel(a)redhat.com> wrote:
>
> Hot deployment is a tricky business always fraught with danger of
> leaving garbage behind, leading to difficult-to-explain slowdowns and
> eventually to out of memory, or to buggy behavior by not properly
> refreshing resources in all the places. By not using it we can save
> ourselves one possible cause for any such symptoms.
Sure, but it's still nice to have if we could support it
>
>
> For production the proper way is to put it in a clustered setup of at
> least two instances. You can then restart one at a time. At least
> that's the idea.
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.
Wildfly cluster deployment would indeed be nice. But would it really
update all instances at the same time rather than do a rolling
deployment? Updating all at once would be a stop-the-world situation
putting everyone on hold while it's going on. As long as you have a
front-end proxy that you can control in some way to redirect traffic
away from one node, then upgrade and restart the node, and repeat for
the other node, you can manually achieve the same - but possibly with
more work, and more error prone, if you don't use good tools to do it
with.
>
>
> For development there is a way to configure Keycloak to load themes
> from your source directory, you can then just refresh your browser to
> see changes.
>
>
> You can set that up like this:
>
> Build the project
> mvn clean install -DskipTests
>
> Open and edit distribution/server-dist/server-provisioning.xml
> Find copy-module-artifacts="true" and change it to
> copy-module-artifacts="false"
>
> I use:
> sed -i ''
>
's/copy-module-artifacts="true"/copy-module-artifacts="false"/'
> distribution/server-dist/server-provisioning.xml
>
> Then only build the server distribution module
> mvn clean install -Pdistribution -pl distribution/server-dist
>
> Finally instruct Keycloak to load themes from source directory. Open
> and edit
>
distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json
>
> Find "dir": "${jboss.server.config.dir}/themes" and change it to
> "dir":
>
"PATH_TO_YOUR_KEYCLOAK_GIT_HOME/forms/common-themes/src/main/resources/theme"
>
> I use:
> sed -i '' 's,"dir":
"${jboss.server.config.dir}/themes","dir":
>
>
"/Users/marko/devel/keycloak/keycloak/forms/common-themes/src/main/resources/theme",'
>
>
distribution/server-dist/target/keycloak*/standalone/configuration/keycloak-server.json
>
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.
>
> On Mon, Jan 18, 2016 at 9:46 AM, Travis De Silva <traviskds(a)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.
> >
> >
> > 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
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
3278
days inactive
3280
days old
11 comments
5 participants
participants (5)
-
Bill Burke -
Juraci Paixão Kröhling -
Marko Strukelj -
Stian Thorgersen -
Travis De Silva