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

[Thomas Darimont]

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