Take a look at ClientAdapter/ClientEntity. The ClientEntity for Mongo just returns the list, while the ClientAdapter does the rest.On 16 August 2016 at 21:06, Dmitry Telegin <firstname.lastname@example.org> wrote: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. DefaultMongoConnectionFactoryP rovider.lazyInit( DefaultMongoConnectionFactoryP rovider.java:156)Seems like KeyCloak's query system doesn't like entities with pseudo-getter methods. Any suggestions?DmitrySounds 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 <email@example.com> wrote:Hi,(As Stian is on vacation now, I'd appreciate if someone other helps me with this feature.)Please take a look https://github.com/keyclo ak/keycloak/compare/2.1.0. Final...cargosoft:KEYCLOAK-332 7(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 annotationso.k.models.mongo.keycloak.adap ters.RealmAdapter: added stubs (throwingUnsupportedOperation Exception)o.k.models.cache.infinispan.Re almAdapter: added attributes caching logico.k.models.cache.infinispan.en tities.CachedRealm: added attributes cache (as Map<String, String>)As for tests, I'm afraid I'll need some guidance. org.keycloak.testsuite.model.M odelTest seems appropriate for that; but it will need support for attributes in RealmRepresentation and RealmManager. Is this the right direction?DmitryOn 18 July 2016 at 22:35, Dmitry Telegin <firstname.lastname@example.org> wrote:Stian,Here we go: https://issues.jboss.org/b rowse/KEYCLOAK-3327If 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 <email@example.com> wrote:Stian,In my provider, session.getContext().getRealm( ) returns an instance of org.keycloak.models.cache.i nfinispan.RealmAdapter. But in order to be able to manage attributes, we need an org.keycloak.models.jpa.RealmA dapter. 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(RealmProvi der.class).getRealm(realm. getId());Realm attributes should be perfect for thatOn 12 July 2016 at 13:42, Mitya <firstname.lastname@example.org> 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