5:29 a.m.
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