[keycloak-dev] new provider deployer working on branch!
Bill Burke
bburke at redhat.com
Fri Aug 19 08:57:09 EDT 2016
On 8/19/16 2:34 AM, Stian Thorgersen wrote:
>
>
> On 18 August 2016 at 19:26, Bill Burke <bburke at redhat.com
> <mailto: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/keycloak/tree/master/examples/providers/domain-extension/src/main/java/org/keycloak/examples/domainextension/jpa
>> <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:
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.
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.
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/6f868c66/attachment.html
More information about the keycloak-dev
mailing list