[keycloak-dev] Documenting SPIs, providers and keycloak-server.json

Stan Silvert ssilvert at redhat.com
Thu Oct 16 09:26:36 EDT 2014


+1 overall.  Comments below.

On 10/16/2014 6:54 AM, Stian Thorgersen wrote:
> To make it easier for users to configure Keycloak I propose we add a self-documenting feature to SPIs and Providers.
>
> This would also allow us to do some sanity check on keycloak-server.json.
>
> To achieve this we would do the following:
>
> 1. Add Spi#getDescription and update all implementations to have a short description about the Spi
This part is a no-brainer.  I think we should do it right away.
> 2. Add ProviderDescription[1] interface, ProviderFactory implementations can optionally implement this interface. All our built-in providers should implement ProviderDescription
I'd like us to give this more thought before we commit.  One of the 
problems I ran into with tighter WildFly integration was that 
keycloak-server.json doesn't translate very well into DMR.   So I'd like 
to see that our config options and types will work with that.

DMR already has two-way JSON translation built in because JSON is used 
as its wire format.  Perhaps we should adopt that as our standard.  It's 
a tiny library and it's very nice to work with.  The public API is only 
three classes.

We would just need to make sure our JSON is readable with 
ModelNode.fromJSONStream().
> 3. Add some sanity check of keycloak-server.json
> 4. Fix config in keycloak-server.json that doesn't follow the spi/provider format (applies to scheduled and theme)
>
> Using the above details we can generate a reference guide to include in the documentation. In the future we could also make it possible to configure through the admin console.
>
> It's only a couple hours work and I'd like to include it in 1.1.0.Beta1.
>
> More details below.
>
> --------------
> #2 Add ProviderDescription
>
> ProviderDescription:
> * String getDescription
> * ConfigOption[] getConfigOptions()
>
> ConfigOption:
> * String getName
> * String getDescription
> * boolean isRequired
> * Type getType
>
> Type (enum)
> * STRING
> * NUMBER
> * BOOLEAN
> * OPTIONS(String.. options)
You'll also need lists, arrays, a "type" type, etc.  DMR already has 
this stuff and it's mature.  I think it would fit perfectly.  Just use 
DMR's ModelType.Type enum instead of your custom enum.

You might also want to think about things like localization of 
getDescription() and using a validation framework in case "isRequired" 
isn't enough.  WildFly has libraries for all that stuff too if we want 
to use it.
>
> --------------
> #4 Fix config in keycloak-server.json
>
> Change:
>
>      "scheduled": {
>          "interval": 900
>      }
>
> To:
>
>      "timer": {
>          "basic":
>            "defaultInterval: 900
>          }
>      }
>
> Change:
>
>      "theme": {
>          "default": "keycloak",
>          "staticMaxAge": 2592000,
>          "cacheTemplates": "${keycloak.theme.cacheTemplates:true}",
>          "cacheThemes": "${keycloak.theme.cacheThemes:true}",
>          "folder": {
>              "dir": "${keycloak.theme.dir}"
>          }
>      }
>
> To:
>
>      "theme": {
>          "provider": "default",
>          "default": {
>              "defaultTheme": "keycloak",
>              "staticMaxAge": 2592000,
>              "cacheTemplates": "${keycloak.theme.cacheTemplates:true}",
>              "cacheThemes": "${keycloak.theme.cacheThemes:true}",
>              "themeDir": "${keycloak.theme.dir}"
>          }
>      }
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



More information about the keycloak-dev mailing list