6:41 p.m.
I still believe within the Keycloak project we should have a simple standalone
bootstrapping mechanism. Then we add separate projects (or modules, but I'd prefer
projects) to add a WildFly/EAP subsystem and a Vert.x module (or whatever it is). I have
no problem with the WildFly/EAP subsystem being the recommended approach to deploying
Keycloak, as this does provide great features for management. I'm less bothered about
classloading (we don't need it as it's a single application unless deployed to a
container) and connection pooling (Hibernate has support for this through third-party
libs).
For WildFly/EAP I believe there was plans to create a core platform with Java EE being an
optional overlay. That would be perfect for Keycloak. However, you'd still need a
subsystem which in my experience is a pain to write (services are quite easy to do, but
management/dmr stuff is horrendous IMO).
I'd be surprised if the productised version of Keycloak doesn't end up running on
top of WildFly/EAP (at least the core, without Java EE). Customers (and our support guys)
already know how to deploy and manage it, so that makes perfect sense.
For the standalone version I was thinking a simple json file to configure the server, with
no additional management tools besides the admin console.
By the way there's not much additional work on this compared to skipping a standalone
version and only going for a WildFly subsystem. There's still a need to manually
bootstrap it on Undertow from the subsystem, we need a configuration mechanism that can be
updated at runtime, etc. Also, a lot of existing JBoss projects already take this approach
(for example Transactions and Infinispan).
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 2 October, 2013 1:48:08 PM
Subject: Re: [keycloak-dev] Server provisioning
On 10/2/2013 8:28 AM, Bill Burke wrote:
> I've been thinking about this a bit. I still think we should consider
> bundling Keycloak distro with JBoss/Wildfly. We'd have to reinvent
> classloading, JDBC connection pooling, dir structure, and non-security
> management. Something, IMO, JBoss does well.
>
I just want to add that JBoss AS is focused on the admin experience. It
would be nice to have a consistent way to do this across our products
which is another reason why distributing Keycloak on top of a JBoss
kernel (EAP or whatever) would be the way to go, IMO.
> On 10/1/2013 11:30 AM, Stian Thorgersen wrote:
>> I've started work on a server bundle and an openshift quickstart. The
>> server bundle contains a main class that starts Undertow with Keycloak
>> deployed. It's available at:
>>
>>
>> If social and mail settings was configured on a realm it could be
>> configured through the admin console instead of through system
>> properties. The admin console would be easier to deploy if it was moved
>> into a separate jar module (web fragment). As a jar it can be included on
>> the classpath and the css/htmls will be available (this is how forms is
>> "deployed").
>>
>
> This is on my todo list. I also want to set up a script for dev mode to
> set up appropriate soft links, etc. so its easy to develop things like
> the admin console.
>
> I was going to start separating out the persistence stuff into a set of
> modules api/, picketlink/, jpa/, and mongo/ will this conflict with
> anything you are doing?
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev