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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt;: > 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(a)googlemail.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)googlemail.com&gt; 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(a)redhat.com&gt;: > >> 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(a)googlemail.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>

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(a)redhat.com&gt;: > 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(a)redhat.com&gt; > 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(a)googlemail.com&gt; 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(a)redhat.com&gt;: >>> >>>> 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(a)googlemail.com&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>