6:32 a.m.
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(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>