[keycloak-dev] Server provisioning

[Bill Burke]

You don't need to write a wildfly/AS7 subsystem.  The only thing you're 
really gonna need to configure is the database.  Even then this can be 
abstracted by a connection pool configured and managed by Wildfly.

Managing connection pools, IP bindings, SSL, directory structures, etc. 
is already available and configurable with a JBoss or Wildfly instance. 
  Why would we want to re-invent how to configure and manage these 
things?  More importantly loadbalancing and cluster capabilities and 
cluster management are not something we'll want to implement ourselves 
either.

IMO, I just don't see any disadvantages of the appliance being contained 
within and distributed with a Wildfly or JBoss EAP distro.  It boots up 
really fast, it is very easy to remove subsystems and modules you don't 
want.  Even the directory structure is flexible.
This is exactly what TorqueBox has done for their distro.

On 10/2/2013 12:41 PM, Stian Thorgersen wrote:
> 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 at redhat.com>
>> To: keycloak-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com