I wrote an JPA example for the new User Storage Provider SPI . 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
* 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. 
* javax.persistence.Persistence.createEntityManagerFactory() did not
work, so I had to call Hibernate APIs directly. Not only that, but
non-simple Hibernate APIs. 
* 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
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?