On 8/19/16 9:04 AM, Stian Thorgersen wrote:

On 19 August 2016 at 14:57, Bill Burke <bburke@redhat.com> wrote:

On 8/19/16 2:34 AM, Stian Thorgersen wrote:

On 18 August 2016 at 19:26, Bill Burke <bburke@redhat.com> wrote:

On 8/18/16 1:13 AM, Stian Thorgersen wrote:

One problem with this approach is that you end up having a separate JDBC connection and transaction even if it uses the same database the Keycloak server uses.

Something we have to fix anyways.  Its on my todo list. 

Take a look at https://github.com/keycloak/keycloak/tree/master/examples/providers/domain-extension/src/main/java/org/keycloak/examples/domainextension/jpa for example which allows adding custom entities to the main EntityManager.

I'm really not a big fan of this extension and this is something I do not want to support for product ever.

Why, please elaborate? IMO it's a really nice and simple way to add a few extra entities for custom providers.

Are you going to make our JPA entity classes public?  If not, what's the point of this extension?  Now that we have real deployers, its now easier to write your own persistence unit.  Take a look at the example:

Has nothing to do with our entity classes. It allows users to easily register an extra entity in our persistence unit, so same connection and transaction and no need to create a persistence unit at all. It also has support for Liquibase so schema is update the same way as with our stuff. Users would then get the EntityManager from the JpaConnectionProvider and be able to get their custom entities from there.

It's simpler than what you have. Doesn't work if folks want a different database and such though.

I disagree.  Its not simpler than using standard EJB/JPA.

@PersistenceContext EntityManager em;

is simpler than

EntityManager em = KeycloakSession.getProvider(JpaConnectionProvider.class);