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(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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(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
>>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
>