Re: [keycloak-dev] Preferred storage mechanism for custom settings

Ah, that simple. Please take a look at the PR. Note: in RealmTest::assertRealm, while comparing initial vs. created realm,  we have to check for inclusion of attributes, not equality (of attribute maps). This is because the JPA realm impl adds a lot of attributes itself, and they're now returned by the endpoint. Dmitry В Ср, 17/08/2016 в 09:44 +0200, Stian Thorgersen пишет: just returns the list, while the ClientAdapter does the rest. wrote: adding attribute methods to org.keycloak.models.entities.RealmEntity (base class for MongoRealmEntity), but ended up with the following: have zero arguments if starts with 'get'. Method: public java.lang.String org.keycloak.models.entities.RealmEntity.getAttribute(java.lang.Str ing) at org.keycloak.models.utils.reflection.MethodPropertyImpl.<init>(Meth odPropertyImpl.java:53) at org.keycloak.models.utils.reflection.Properties.createProperty(Prop erties.java:44) at org.keycloak.models.utils.reflection.PropertyQuery.getResultList(Pr opertyQuery.java:168) at org.keycloak.models.utils.reflection.PropertyQuery.getWritableResul tList(PropertyQuery.java:140) at org.keycloak.connections.mongo.impl.MongoStoreImpl.getEntityInfo(Mo ngoStoreImpl.java:433) at org.keycloak.connections.mongo.impl.MongoStoreImpl.<init>(MongoStor eImpl.java:101) at org.keycloak.connections.mongo.DefaultMongoConnectionFactoryProvide r.lazyInit(DefaultMongoConnectionFactoryProvider.java:156) pseudo-getter methods. Any suggestions? support for Mongo as well though as we can't accept it otherwise. to org.keycloak.testsuite.admin.realm.RealmTest which would also make sure attributes work correctly when added through the admin endpoints. wrote: helps me with this feature.) /2.1.0.Final...cargosoft:KEYCLOAK-3327 I'll rebase it onto master if needed) jpa.RealmAdapter) (throwing UnsupportedOperationException) caching logic attributes cache (as Map<String, String>) 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? wrote: fields and getters/setters) I think I could work on a PR as well. entities it's just a matter of exposing through RealmModel and add tests for it. via Entity SPI are not by default cache-enabled (and won't be synchronized between the nodes in clustered environment)? matter of providing Infinispan adapters similar to existing ones for Realm/User/Role/Client etc.? 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). 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. to hard to get right. For custom entities you should use Hibernate 2nd level cache. 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. wrote: 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? session.getProvider(RealmProvider.class).getRealm(realm .getId()); wrote: 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? ev