[keycloak-dev] Server provisioning

[Stian Thorgersen]

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
>