8:39 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: keycloak-dev(a)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