[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