[keycloak-dev] creating JPA user storage provider difficult

[Bill Burke]

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.

>
>>>> * 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.

Bill