On Jun 4, 2014, at 12:23 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
There is of course ways to paper over this and shove them together
but you end up with leaky abstractions. Like lets say the CLI could issue REST operations
against Keycloak as well. Thats great but that means things like the compensating
transaction model don’t let you mix management changes with keycloak changes.
Another issue is that WildFly has some pretty strict backwards compatibility contracts
with regards to management that stem from EAP. Keycloak, at this stage of the process
might not want to put up with us requesting similar conservative governance. It might be
better for us to limit the API dependencies to best enable the project to continue to
evolve.
Other problems I forgot to mention (oops sorry!)
1. Lifecycle robustness problems - Management is not supposed to affect applications, so
if the user takes down or moves the DC it would take down application auth as well - Bad!
2. Chicken-egg problems in standalone mode - subsystems aren’t started when the server is
in admin-only mode. (Although this one is solvable)
3. Lots of additional work.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat