By the way the custom entities thingy can be used with your new deployer as well. It's just a simpler way to add one or two custom entities.

On 19 August 2016 at 15:04, Stian Thorgersen <sthorger@redhat.com> 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. 



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.
 

For JEE devs yes.
 

Also, with this extension, you have the possibility of customers being dependent on our data model and the data model becomes something that needs to be backward compatible. 

Nah - because our entities is in a private module and they'll get a warning if they include that in their provider.
 

Bill