[keycloak-dev] creating JPA user storage provider difficult

[Marek Posolda]

On 04/08/16 16:03, Bill Burke wrote:
>
>
> On 8/4/16 9:56 AM, Marek Posolda wrote:
>> Yep, so we can address this with some sort of "deployer" you 
>> proposed, which will have automatically access to JEE APIs, so people 
>> won't need to declare dependencies on them anywhere? Still people 
>> always need to deal with modules though, if they don't want just JEE, 
>> but also some other different 3rd party dependencies...
> True, but at least we can make a keycloak deployer that is consistent 
> with WARs, etc.  Meaning, those that are experienced writing WARs in 
> Wildfly and using jboss-deployment-structure.xml will not have to be 
> completely retrained to write a keycloak component.
+1
>
>>
>>>>> * Had to use JpaKeycloakTransaction to enlist EntityManager with
>>>>> keycloak transactions.  This means using EJBs is out of the question.
>>>>>
>>>>> This is unacceptable.  Keycloak is supposed to be simple and this is
>>>>> extremely difficult.  When Keycloak was an exploded WAR you could use
>>>>> every Java EE component type as you could just plop your extensions
>>>>> within META-INF/lib.  Classloading was simple as it was all the same
>>>>> classloader.
>>>>>
>>>>> Going forward we need to write an actual deployer for Keycloak
>>>>> extensions that allow you to define Keycloak providers within EE 
>>>>> jars,
>>>>> ears, etc.  Writing an extension to Keycloak should be as easy as
>>>>> writing a Java EE application.  Extension developers should be 
>>>>> able to
>>>>> leverage the entire JBoss/Wildfly platform. Minimally, we also 
>>>>> need to
>>>>> begin and commit/rollback a UserTransaction within a Keycloak request
>>>>> flow so that transaction EE and Spring component layers can function.
>>>> +1 for deployer. Maybe we can try to prototype an example, which 
>>>> uses stuff like EJB and then see what exactly we need to add?
>>>>
>>>> For UserTransaction, we can maybe have the KeycloakTransaction 
>>>> implementation, which will delegate to UserTransaction? Then people 
>>>> can optionally enlist it in their provider if they need it :
>>>>
>>>> session.getTransactionManager().enlistAfterCompletion(new 
>>>> UserTransactionWrapper());
>>>>
>>>> Then Keycloak will automatically take care of commit/rollback this 
>>>> transaction at end of request.
>>> Why wouldn't they just use UserTransaction?
>> In case that KeycloakTransaction is rolled back, then it calls 
>> rollback to all the enlisted delegates. So enlisted 
>> UserTransactionWrapper will then call UserTransaction.rollback as well.
>>
>> Unless we're going to rewrite our transaction API to use JTA? That 
>> will automatically integrate with JPA and infinispan. If people needs 
>> to enlist their own transaction, they need to implement 
>> javax.transaction.xa.XAResource. This looks slightly more complicated 
>> then implement our KeycloakTransaction, but on the other hand, it's a 
>> standard.
>>
> I think we can/should have both.  We automatically begin and enlist a 
> UserTransactionWrapper into the KeycloakTransactionManager at the 
> beginning of a request (in our filter that starts a KeycloakSession).  
> If users want something XA then they implement and integration with 
> JTA.  If they want something simpler, than use our KeycloakTransactions.
+1 assuming that automatically enlist UserTransaction in each request 
won't have any performance (or other) impact.

Marek
>
> Bill