[keycloak-dev] Example Setup to simplify the development of Keycloak Extensions

Stian Thorgersen sthorger at redhat.com
Mon Feb 18 04:34:25 EST 2019

For development you don't need to restart the server. Just run it manually
and configure Arquillian to connect to a remote instance. That'll give you
even faster roundtrips than KeycloakServer does.

On Mon, 18 Feb 2019 at 10:32, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello Stian,
> I agree with most of your points! Using your internal test-infrastructure
> is definitely not a long-term solution as it can be quite brittle.
> Additionally the actual environment available in a real Keycloak-Server
> (Java EE) is quite different from that provided by the KeycloakServer
> standalone approach (no EJB, JNDI etc.).
> Nevertheless, I think using the KeycloakServer can be a pragmatic solution
> (at the moment) for faster development of smaller components like
> custom Authenticators, RequiredActions, FormActions, PasswordHashes but
> not so much for UserStorageProviders etc.
> Repeatedly starting / stopping a wildfly or arquillian container can be
> quite slow in my experience - do you have a setup that starts < 3 seconds?
> Perhaps using the wildfly-swarm / thorntail (https://thorntail.io/) would
> be a better middle-ground solution here, as it would provide a
> "close-enough"
> environment to what's available in wildfly including fast boot times.
> Cheers,
> Thomas
> Am Mo., 18. Feb. 2019 um 10:15 Uhr schrieb Stian Thorgersen <
> sthorger at redhat.com>:
>> Adding a few reasons why it should target a real distro and not the
>> KeycloakServer internal util:
>> * KeycloakServer is an internal util that we use for our testsuite. This
>> is not something we will support publicly as we need to be able to change
>> this without considering backwards compatibility.
>> * As an extension developer you should not modify Keycloak code itself.
>> This is actually what makes our testsuite more complex as we do need to be
>> able to quickly run tests with a modified Keycloak server.
>> * Using a dist you can test it properly. There is no guarantee that your
>> extension will work deployed to Keycloak dist if it works on
>> KeycloakServer. Classpath being one main issue here, but there are other
>> caveats as well. So you end up having to run your tests twice (once with
>> embedded Keycloak for development and second with proper dist for proper
>> testing)
>> For the above reasons although this is a nice approach for now it's not
>> very future proof and I'd rather see efforts being put into doing it
>> "properly" and improving on that experience than working around it.
>> On Mon, 18 Feb 2019 at 10:10, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>> Arquillian can use a remote container, which allows you pointing to an
>>> already running Keycloak server, then you simply hot deploy your extension
>>> as part of the tests and it should not need to restart Keycloak.
>>> On Tue, 12 Feb 2019 at 12:32, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>> HI Stian,
>>>> Thanks for the feedback. In my experience using Arquillian is rather
>>>> slow - at least I haven't seen an example setup that doesn't need 30+
>>>> seconds round-trip time per change (without hot-code replacement). Do you
>>>> have a fast example at hand (< 10sec round-trip time)?
>>>> The aforementioned approach is easy to use and makes a cold-start
>>>> round-trip much faster (~5 sec my machine).
>>>> Also one can concentrate on the actual extension development first,
>>>> instead of figuring out the proper packaging of their extension right from
>>>> the beginning, which is IMHO not a nice getting started experience.
>>>> Cheers,
>>>> Thomas
>>>> Am Di., 12. Feb. 2019 um 12:21 Uhr schrieb Stian Thorgersen <
>>>> sthorger at redhat.com>:
>>>>> I'd say it would be better to target the real distribution rather than
>>>>> the KeycloakServer. It should be reasonably easy to setup Arquillian to use
>>>>> the Keycloak distribution from Maven Central and allow it to hot-deploy
>>>>> extensions for testing purposes.
>>>>> On Tue, 12 Feb 2019 at 09:42, Thomas Darimont <
>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>> Hello Keycloak-Team,
>>>>>> I found a neat setup to simplify the development of Keycloak
>>>>>> extensions.
>>>>>> I setup a "keycloak-extension-playground" project that contains two
>>>>>> or more
>>>>>> maven modules:
>>>>>> - keycloak-playground-server
>>>>>> - simple-auth-extension (example)
>>>>>> In the "keycloak-playground-server" module, I wrap a KeycloakServer
>>>>>> from
>>>>>> the "keycloak-testsuite-utils" library where one could potentially add
>>>>>> additional configuration. Note that this library must be in (local)
>>>>>> Maven
>>>>>> Repository.
>>>>>> The "simple-auth-extension" is an example extension module that
>>>>>> demonstrates the usage of the Authenticator SPI.
>>>>>> I now declare "simple-auth-extension" as a compile time dependency of
>>>>>> the
>>>>>> "keycloak-playground-server" project. This ensures that it's classes
>>>>>> and
>>>>>> resources are on the classpath of KeycloakServer. Therefore all SPI
>>>>>> implementations in custom extensions can be found. This improves the
>>>>>> debugging experience and speeds up development time.
>>>>>> The example project can be found here:
>>>>>> https://github.com/thomasdarimont/keycloak-extension-playground
>>>>>> What do you guys think about this approach?
>>>>>> Cheers,
>>>>>> Thomas
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

More information about the keycloak-dev mailing list