1:42 a.m.
The user storage example leverages this approach. It should be documented
in the server developer guide.
You can't deploy custom SPIs this way only providers. For a custom SPI
you'd have to deploy that as a module, restart the server, then you can
deploy your custom providers for your custom SPIs.
On 4 April 2017 at 16:32, Martin Hardselius <martin.hardselius(a)gmail.com>
wrote:
Is this documented somewhere (I can't seem to find it)?
How would that work for completely custom SPIs with their own
configuration? We make heavy use of standalone-ha.xml to configure
providers with environment variables, which in turn are injected into the
containers by Kubernetes.
On Tue, 4 Apr 2017 at 15:54 Stian Thorgersen <sthorger(a)redhat.com> wrote:
> Use the new JEE deployer approach. Then you can deploy and re-reploy
> providers live to the server with simply running "mvn wildfly:deploy".
>
> On 4 April 2017 at 14:57, Martin Hardselius <martin.hardselius(a)gmail.com>
> wrote:
>
> Hi,
>
> I would like to know more on how people are approaching building and
> testing of custom modules / installations.
>
> In our current setup we have a repo where we develop all our custom code.
> We use gradle and the 'com.github.zhurlik.jbossmodules' plugin to build
> wildfly modules from that code. Then we create a new custom docker image
> from the keycloak base image and those built modules. After we've built
> our
> custom image, a separate repo with integration tests / security tests /
> etc. is built, targeting the newly created image. If everything checks
> out,
> the image is deployed in our kubernetes cluster. Every step of the process
> is automated and works kind of ok.
>
> What I really don't like is the separation of our "module/SPI repo"
and
> our
> test suite. Ideally, I would like to write all my integration tests in the
> same repo as the code that I'm testing and be able to fire them against a
> running keycloak server (with my code deployed) from within my IDE. Does
> this make sense? Has anyone done something like this? Is there an
> alternative way to build our custom images that is better suited?
>
> Looking forward to a discussion on this.
>
> Regards,
> Martin
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>