On 6/30/2014 12:37 PM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Monday, 30 June, 2014 5:25:31 PM
> Subject: Re: [keycloak-dev] Refactoring to KeycloakSession and ProviderSession
>
> Ugh...Why? Would have been cool to discuss this before you did this.
> There was a clear separation of things prior to this change:
>
> * ProviderSession was for resolving various session based APIs I thought.
> * KeycloakSession was analogous to EntityManager or HibernateSession.
I didn't really think it was a big deal, as the separation is still there. What used
to be KeycloakSession is now ModelProvider, and the new KeycloakSession is just a wrapper
to be able to get to both from the same @Context injection.
KeycloakSession now mixes up the provider API and the data model. What
exactly is the benefit of that? I thought we were moving to
*separating* things out not combining them.. Realm meta-model, User
metamodel, and User Session meta model.
What I'd like to see is ProviderSession becoming a mini-transaction
manager where our Filter calls commit/rollback on the ProviderSession
which in turn, calls commit/rollback on all our model APIs.
>
> Also, you don't go committing stuff that breaks existing code...i.e. the
> caching stuff I did.
I commented out the cache stuff as it wasn't working, see
https://issues.jboss.org/browse/KEYCLOAK-527. I tried to fix it, but couldn't quite
figure out how to go about doing it, so thought it was best to disable it until you got
back and could have a look. I was going to send you an email about it, but of course I
forgot that :(
I guess we don't have any tests for adding/removing scope mappings :(
FYI, it is just a matter of using EntityManager.getReference(). Commit
incoming.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com