I wrote an JPA example for the new User Storage Provider SPI [1]. It was very difficult to figure out how to wire in JPA. I'm going to take a guess that very very few users have actually tried to implement a JPA-based User Federation Provider. They would have run into a ton of hurdles. * Putting just a jar within the "providers/" directory is unusable. JPA classes and other dependencies will not be visible. * So, you have to craft a *CORRECT* module.xml file and know exactly which dependencies to bring in. [2] * javax.persistence.Persistence.createEntityManagerFactory() did not work, so I had to call Hibernate APIs directly. Not only that, but non-simple Hibernate APIs. [3] * When configuring JPA I also had to know what classloader to use so that persistence.xml was visible.

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

Finally, we should just remove the "providers/" directory as I don't think it is very usable for actual extension writing. What I didn't try was adding all jars needed (Hibernate etc.) within the providers directory. Would that have worked?

[1] https://github.com/patriot1burke/keycloak/tree/master/examples/providers/... [2] https://github.com/patriot1burke/keycloak/blob/master/examples/providers/... [3] https://github.com/patriot1burke/keycloak/blob/master/examples/providers/... _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 8/4/16 4:00 AM, Marek Posolda wrote: > On 04/08/16 01:48, Bill Burke wrote: >> I wrote an JPA example for the new User Storage Provider SPI [1]. It >> was very difficult to figure out how to wire in JPA. I'm going to take >> a guess that very very few users have actually tried to implement a >> JPA-based User Federation Provider. They would have run into a ton of >> hurdles. >> >> * Putting just a jar within the "providers/" directory is unusable. >> JPA >> classes and other dependencies will not be visible. >> >> * So, you have to craft a *CORRECT* module.xml file and know exactly >> which dependencies to bring in. [2] >> >> * javax.persistence.Persistence.createEntityManagerFactory() did not >> work, so I had to call Hibernate APIs directly. Not only that, but >> non-simple Hibernate APIs. [3] >> >> * When configuring JPA I also had to know what classloader to use so >> that persistence.xml was visible. > In some recent release, we added JpaEntityProvider SPI. This allows > to register your own JPA entities with Keycloak own EntityManager . > So in your provider, you don't need to care about the complex stuff > like proprietary Hibernate API, classloader or transaction enlisting. > The JpaEntityProvider SPI extends the keycloak persistence unit. Not very useful if you are integrating some other external RDBMs.

> We have a docs [1] and example for that [2] > > [1] > https://keycloak.gitbooks.io/server-developer-guide/content/v/2.1/topics/... > [2] > https://github.com/patriot1burke/keycloak/tree/master/examples/providers/... > > > That's much easier, isn't it? Just not sure if it helps with EJB... Easier if you don't need any other dependency defined. What if they want to JAX-RS client and a specific provider from Resteasy? As I mentioned in a previous point, its just not as simple as including the modules. Persistence.createEMF() doesn't work as the classloaders all seem confused.

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

Bill

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

+1 To dropping provider directory as it's not very useful for real providers. Deployer would be awesome, especially if we can leverage jboss-deployment-structure.xml as an alternative to modules and Maven deploy plugin. Sounds like a lot of work though. There's also the issue around not supporting applications deployed directly to Keycloak. For a long time ago I built a server which used regular old JEE session beans as plugins. All you needed to to was to register it globally in JNDI and the server would scan for implementations of specific classes. It was a bit of a pain when it came to life cycle (beans would need to be deployed before the server, etc.). Worked quite well though ;) On 5 August 2016 at 10:36, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: 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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>