[keycloak-dev] Keycloak distribution changes

[Stian Thorgersen]

I don't see how splitting the sub-system will make it more difficult for Elytron or OOTB config for examples. Anything we add to those should be just as usable whether or not Keycloak is running locally or remotely.

Splitting the sub-system has the advantages of isolating two very different features. Deploying and configuring Keycloak itself should be completely separated from configuring applications that use Keycloak. It makes the distribution of either cleaner. Also, for the server sub-system we only need to support latest WildFly and the distribution we build on-top of WildFly core/servlets-only. While for the adapter sub-system we'll need to support a range of EAP versions as well as potentially multiple WildFly versions.

Other than some initial boiler plating I don't see any benefits of having a single sub-system, and it'll be much easier to maintain two separate sub-systems IMO as they do two completely different things and it should be possible to deploy a single one of the sub-system or both together.

----- Original Message -----
> From: "Marko Strukelj" <mstrukel at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 14 April, 2015 12:29:30 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> Yesterday a had a little conversation with Stan, and he thought the code
> split may result in a lot of subsystem plumbing code duplication and make
> things more difficult for Elytron integration, and make OOTB config for
> examples slightly more complicated ...
> 
> As far as I understood it the idea is a code split, and module dependencies
> split, and it's there to be able to make a standalone distribution that will
> not contain any of adapter-specific configuration / dependencies / modules.
> The price of duplicated plumbing, and a lack of OOTB adapter configuration
> for standalone  - server and adapter in the same WildFly - is agreed to be
> outweighed (so I understand) by some benefits - but I'm not sure what those
> are (cleaner codebase? The ability to be able to install adapter only into
> existing WildFly without also installing the server parts - auth-server.war?
> Something else?)
> 
> Server / adapter split will have to identify code that is shared between
> server and adapter, which will be modularized out of the subsystem.
> 
> Stan can tell more, but as I understood his idea was that the one and single
> subsystem could present two faces, and based on availability of some modules
> for example present a server only, an adapter only, or a full view of
> configuration options, and that might be simpler than splitting existing
> subsystem into three parts - server, adapter, shared.
> 
> 
> ----- Original Message -----
> > We've discussed this and I hope we're all on the same page, but just to
> > confirm here's what we've discussed:
> > 
> > Keycloak Server
> > ---------------
> > 
> > * Standalone
> >   - Built on WildFly servlet-only
> >   - No 'standalone/deployments' directory
> >   - Includes server only sub-system
> >   - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc,
> >   included)
> >   - Keycloak deployed to root context (http://localhost:8080)
> > * Demo Bundle
> >   - Built on WildFly full
> >   - Includes demo ready deployed and configured
> >   - Includes server and adapter sub-systems
> >   - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
> >   examples, etc.)
> >   - Keycloak deployed to auth context (http://localhost:8080/auth)
> > * Installer
> >   - Installs Keycloak server sub-system into existing WildFly
> >   - Only "latests" WildFly at the time of release is supported
> >   - Keycloak deployed to auth context (http://localhost:8080/auth)
> > 
> > 
> > Keycloak Embedded
> > ------------------
> > 
> > * Consumed by external JBoss projects to embed Keycloak
> > * Build-your-own WAR example repo
> > 
> > 
> > Keycloak Adapters
> > -----------------
> > 
> > * Separate download from server
> > * Installer for WildFly subsystem adapter
> > * We still have to decide if adapters should have a separate release
> > cycle/version to the server
> > * We still have to decide if Java adapters should be moved to separate
> > github
> > repo
> > 
> > 
> > Finally, a set of releated tasks
> > --------------------------------
> > 
> > * Split subsystem into server and adapter
> > * Use standalone.xml instead keycloak-server.json (json will still be
> > supported for embedded)
> > * Add support to use dmr/jboss-cli for configuring the server (for example
> > a
> > single jboss-cli batch script can add data-source and set Keycloak to use
> > it)
> > * Add support to use dmr/jboss-cli for configure realms, apps and users
> > * Add support to use root-context with server subsystem
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
>