[keycloak-dev] Server provisioning

Thu Oct 3 08:12:37 EDT 2013

Err, why is deploying a set of wars such a problem?  I'm not seeing it. 
  A WAR is a deployment unit that we can provide for people that want to 
run it with Tomcat, Jetty, or even Glassfish, et. al.

On 10/3/2013 4:14 AM, Stian Thorgersen wrote:
> Ok, you've convinced me, but I don't see how we're going to deploy Keycloak on WildFly if it's not a subsystem (or are you only referring to the management part)? Deploying a set of WARs is certainly not the right approach IMO.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 2 October, 2013 8:33:33 PM
>> Subject: Re: [keycloak-dev] Server provisioning
>>
>> 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
>>

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