Re: [keycloak-dev] creating JPA user storage provider difficult

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