Hi,
I've started implementing attributes for Mongo. I've begun with adding
attribute methods to org.keycloak.models.entities.RealmEntity (base
class for MongoRealmEntity), but ended up with the following:
java.lang.IllegalArgumentException: Invalid accessor method, must have zero arguments if
starts with 'get'. Method: public java.lang.String
org.keycloak.models.entities.RealmEntity.getAttribute(java.lang.String)
at
org.keycloak.models.utils.reflection.MethodPropertyImpl.<init>(MethodPropertyImpl.java:53)
at org.keycloak.models.utils.reflection.Properties.createProperty(Properties.java:44)
at
org.keycloak.models.utils.reflection.PropertyQuery.getResultList(PropertyQuery.java:168)
at
org.keycloak.models.utils.reflection.PropertyQuery.getWritableResultList(PropertyQuery.java:140)
at
org.keycloak.connections.mongo.impl.MongoStoreImpl.getEntityInfo(MongoStoreImpl.java:433)
at
org.keycloak.connections.mongo.impl.MongoStoreImpl.<init>(MongoStoreImpl.java:101)
at
org.keycloak.connections.mongo.DefaultMongoConnectionFactoryProvider.lazyInit(DefaultMongoConnectionFactoryProvider.java:156)
Seems like KeyCloak's query system doesn't like entities with pseudo-
getter methods. Any suggestions?
Dmitry
> Sounds like you're on the right track. You'd need to
implement
support for Mongo as well though as we can't accept it otherwise.
> > > With regards to tests I'd add
to org.keycloak.testsuite.admin.realm.RealmTest which would also make
sure attributes work correctly when added through the admin
endpoints.
> > On 13 August 2016 at 16:47, Dmitry Telegin <mitya(a)cargosoft.ru>
wrote:
> Hi,
> > > (As Stian is on vacation now, I'd appreciate if someone other helps
me with this feature.)
.0.Final...cargosoft:KEYCLOAK-3327
>
> > > (it has been branched off 2.1.0.Final for the ease of testing, I'll
rebase it onto master if needed)
>
> > > o.k.models.RealmModel: added methods (borrowed signatures from
jpa.RealmAdapter)
> o.k.models.jpa.RealmAdapter: added @Override annotations
> > > o.k.models.mongo.keycloak.adapters.RealmAdapter: added stubs
(throwing UnsupportedOperationException)
> > > o.k.models.cache.infinispan.RealmAdapter: added
attributes caching
logic
> > > o.k.models.cache.infinispan.entities.CachedRealm:
added attributes
cache (as Map<String, String>)
>
> > > > > > > As for tests, I'm afraid I'll need some
guidance.
org.keycloak.testsuite.model.ModelTest seems appropriate for that;
but it will need support for attributes in RealmRepresentation and
RealmManager. Is this the right direction?
>
> Dmitry
>
> >
> > > > > > > > On 18 July 2016 at 22:35, Dmitry Telegin
<mitya(a)cargosoft.ru>
wrote:
> > > Stian,
> > > Here we
go: https://issues.jboss.org/browse/KEYCLOAK-3327
> > >
> > > > > > > If the fix is somewhat trivial (i.e. a matter of
adding fields
and getters/setters) I think I could work on a PR as well.
> > >
> > >
> > > > > > > > As the attributes are already available in the
underlying
entities it's just a matter of exposing through RealmModel and
add tests for it.
> >
> > > > > > > > > > > BTW, does this mean that all the
custom entities provided via
Entity SPI are not by default cache-enabled (and
won't be
synchronized between the nodes in clustered environment)?
> > > > > > > > > > > If so, will it
be easy to cache-enable them? Is this just a
matter of providing Infinispan adapters
similar to existing
ones for Realm/User/Role/Client etc.?
> > >
> > >
> > > > > > > > > > > > > > There's no
caching for custom entities. I'd recommend using
Hibernate 2nd level cache for
it as it's rather tricky to create
a custom one. We have our custom one because we need to support
Mongo as well as users from different sources (user federation
and identity brokering).
> >
> > > > > > > > > > > > > > > > > >
> > > > > Ideally, I'd like to see a current domain-extension example
augmented with Infinispan cache functionality. I've got some
ideas on a detailed walkthrough tutorial for building complete,
full-featured KeyCloak extensions (it's a big topic I'll
elaborate on a bit later); I think Infinispan-enabled entities
could be covered there, too.
> > >
> > >
> > > > > > > > No chance we're adding cache for custom
entities. It's just to
hard to get right. For custom entities you should use
Hibernate
2nd level cache.
> >
> > > Regards,
> > > Dmitry
> > >
> > > В Пн, 18/07/2016 в 07:39 +0200, Stian Thorgersen пишет:
> > > > > > > > > > > > > > > > > >
> Forgot that attributes are not exposed through RealmModel.
You can't access
the JPA RealmAdapter directly as you'll
break the cache functionality. You can create a JIRA to
request attributes added to RealmModel though.
> > > > > > > > > On 15 July 2016 at
20:28, Mitya <mitya(a)cargosoft.ru> wrote:
> > > > > Stian,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > In my
provider, session.getContext().getRealm() returns an
instance
of org.keycloak.models.cache.infinispan.RealmAdapter. But
in order to be able to manage attributes, we need an
org.keycloak.models.jpa.RealmAdapter. What's the best way
to obtain it?
> > > > >
> > > > > I've yet come up with the following:
> > > > >
> > > > > RealmModel realm = session.getContext().getRealm();
> > > > > > > > > > > > > > > > >
RealmAdapter adapter = (RealmAdapter)
session.getProvider(RealmProvider.class).getRealm(realm.get
Id());
> > > > >
> > > > >
> > > > > > Realm attributes should be perfect for that
> > > > > > > > > > > > > > > > > >
> > On 12 July 2016 at 13:42, Mitya <mitya(a)cargosoft.ru>
wrote:
> > > > > > > Hi,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > I'm developing a KeyCloak extension, and I want some
custom
(per-realm) parameters to be tuned via the GUI
form. Speaking of the storage mechanism for my
settings, are realm attributes suitable for that? or
should I create a dedicated custom entity instead?
> > > > > > >
> > > > > > > Thx,
> > > > > > > Mitya
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > >
> > > > > > > keycloak-dev mailing list
> > > > > > >
> > > > > > > keycloak-dev(a)lists.jboss.org
> > > > > > >
> > > > > > >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>