[keycloak-dev] Making ServerInfoAdminResource::ENUMS mutable

[Stian Thorgersen]

On 18 October 2016 at 21:57, Dmitry Telegin <mitya at cargosoft.ru> wrote:

> Hi Stian,
>
> I completely agree on the first point, this deserves a better solution.
> But knowing that it would require digging deep into the guts of KeyCloak, I
> just didn't dare :)
>
> I would see providers somehow registering their custom enum keys, either
> via API call or via callback, and KeyCloak would maintain the list of
> custom values per provider. ServerInfoAdminResource then could return a
> combined list of enum keys, both built-in and defined by providers. But I'm
> afraid that would require changes to API and/or interfaces. What do you
> think? How would you approach this problem yourself?
>

We have SPIs to make features pluggable so that's the way to go. We'd
probably want a AdminResourceTypeSpi and at the same time refactor the
current enum to use this.


>
> And BTW, what's wrong with the second PR? The github comment seems a bit
> unclear, so could you please elaborate? It has completely different scope,
> though deals with the same feature. It's not about exposing anything via
> static methods, it's about making ResourceType extensible, following a
> well-defined pattern. I was sure that Marek supported it, and I've
> implemented it in accordance with his recommendations.
>

Seemed rather hacky to me, but maybe I'm mistaking something. Can you show
an example on how it would actually be used? I don't see how you'd add
additional types and how you'd actually use the resource type not knowing
what type it is. Seems all operations valid on an enum becomes invalid in
this case.


>
> Please forgive my persistence, but I consider this an important feature.
> What we love about KeyCloak is its total extensibility. Having custom
> entities and realm resources is great, but not being able to log their
> events leaves a sensation of incompleteness.
>

NP, I appreciate and welcome it. However, bear in mind that we can't
accommodate every wish. Adding loads of little things used by only one user
would bloat the code base. At the very least it has to be well designed,
generically usable and documented.


>
> Cheers,
> Dmitry
>
> I don't like the PRs you've sent at all. It's all very hacky, calling
> static methods on other classes is far from elegant. I've rejected both
> PRs. It also ends up being completely undocumented so no-one except you
> would know about this.
>
> On 17 October 2016 at 21:15, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>
> JIRA https://issues.jboss.org/browse/KEYCLOAK-3711
> PR https://github.com/keycloak/keycloak/pull/3337
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>