[keycloak-dev] Server provisioning

[Stian Thorgersen]

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
>