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

Bill Burke bburke at redhat.com
Fri Aug 19 10:21:34 EDT 2016



On 8/19/16 10:13 AM, Bill Burke wrote:
>
>
>
> On 8/19/16 9:04 AM, Stian Thorgersen wrote:
>>
>>
>> On 19 August 2016 at 14:57, Bill Burke <bburke at redhat.com 
>> <mailto: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
>>>     <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:
>>
>>
>> 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.
> I disagree.  Its not simpler than using standard EJB/JPA.
>
> @PersistenceContext EntityManager em;
>
> is simpler than
>
> EntityManager em = 
> KeycloakSession.getProvider(JpaConnectionProvider.class);
>
Another reason standard EJB/JPA is simpler is that JpaConnectinProvider 
*requires* the developer to know and write liquibase XML for their new 
entities.  This is a real pain in the ass.  Standard JPA, the schema can 
be created/updated automatically.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160819/50cbd16e/attachment.html 


More information about the keycloak-dev mailing list