[keycloak-dev] Refactoring to KeycloakSession and ProviderSession

[Bill Burke]

On 6/30/2014 12:37 PM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at 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