I disagree. Its not simpler than using standard EJB/JPA.
On 19 August 2016 at 14:57, Bill Burke <bburke@redhat.com> wrote:
On 8/19/16 2:34 AM, Stian Thorgersen wrote:
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:
On 18 August 2016 at 19:26, Bill Burke <bburke@redhat.com> wrote:
On 8/18/16 1:13 AM, Stian Thorgersen wrote:
Something we have to fix anyways. Its on my todo list.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.
I'm really not a big fan of this extension and this is something I do not want to support for product ever.Take a look at https://github.com/keycloak/keycloak/tree/master/examples/pr for example which allows adding custom entities to the main EntityManager.oviders/domain-extension/src/ main/java/org/keycloak/example s/domainextension/jpa
Why, please elaborate? IMO it's a really nice and simple way to add a few extra entities for custom providers.
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.