[keycloak-dev] new provider deployer working on branch!

[Stian Thorgersen]

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

>
>
> On 8/19/16 2:34 AM, Stian Thorgersen wrote:
>
>
>
> On 18 August 2016 at 19:26, Bill Burke <bburke at 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/ke
>> ycloak/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.


>
> https://github.com/keycloak/keycloak/tree/master/examples/
> providers/user-storage-jpa/src/main/java/org/keycloak/
> examples/storage/user
>
> Coding EJB and JPA is really easy, simple and fast.
>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/6be06d44/attachment-0001.html