[keycloak-dev] keep exploded war and add exploded themes

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 21 July, 2014 2:30:27 PM
> Subject: Re: [keycloak-dev] keep exploded war and add exploded themes
> 
> 
> 
> On 7/21/2014 4:35 AM, Stian Thorgersen wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 18 July, 2014 10:48:21 PM
> >> Subject: [keycloak-dev] keep exploded war and add exploded themes
> >>
> >> I want to always keep an exploded WAR.  Additionally, I'd like to
> >> explode all built-in themes in WEB-INF/classes.  People are going to
> >> want to see how its done and will need concrete examples.
> >
> > What's the use-case for the exploded WAR?
> >
> > I don't see any need in exploding the themes, they're already exploded to
> > standalone/configuration/themes.
> >
> 
> Whoops, forgot about that.
> 
> >>
> >> For example, one of the things I want to do with Federation plugins is
> >> that users can create their own management page for their plugin.  They
> >> will need to see examples/templates from the existing admin consoole.
> >
> > I don't think that's a very elegant way to "extend" the console. A much
> > better approach would be to then investigate UberFire or Hawt.
> >
> > My idea for managing providers was that we'd add a generic mechanism for
> > configuring. That would be much simpler to use for folks than having to
> > create (and maintain) their own additional pages in the admin console. I
> > thought we had agreed that we where doing that for 1.0.beta4?
> >
> 
> 1) Uberfire/Hawt isn't going to provide a mechanism to plug in a REST
> backend, are they?
> 2) I'd like LDAP to be treated as a plugin, not a special case, yet, I
> want a nice admin screen for it as it is a feature everybody wants.

After thinking about it some more I think it would be cool to have this available. When creating a plugin/provider you can either use:

* Simple configuration - This will provide a simple form which queries the provider for what keys to populate the form with. On the backend this will use a generic rest endpoint that lets you update a map with config for the provider, and is stored in the db.
* Advanced configuration - This will let you add your own REST backend and admin page as you suggested. Not sure how we'd deal with persistence of this data though.

We kinda need the advanced configuration any ways as we'd like built features to be enabled/disabled on the admin endpoints/console.

I'll write a separate mail about the ideas I had with provider configuration then we can carry on the discussion there.

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