On 04/08/16 16:03, Bill Burke wrote:
>
>
> On 8/4/16 9:56 AM, Marek Posolda wrote:
>> Yep, so we can address this with some sort of "deployer" you
>> proposed, which will have automatically access to JEE APIs, so people
>> won't need to declare dependencies on them anywhere? Still people
>> always need to deal with modules though, if they don't want just JEE,
>> but also some other different 3rd party dependencies...
> True, but at least we can make a keycloak deployer that is consistent
> with WARs, etc.  Meaning, those that are experienced writing WARs in
> Wildfly and using jboss-deployment-structure.xml will not have to be
> completely retrained to write a keycloak component.
+1

>
>>
>>>>> * Had to use JpaKeycloakTransaction to enlist EntityManager with
>>>>> keycloak transactions.  This means using EJBs is out of the question.
>>>>>
>>>>> This is unacceptable.  Keycloak is supposed to be simple and this is
>>>>> extremely difficult.  When Keycloak was an exploded WAR you could use
>>>>> every Java EE component type as you could just plop your extensions
>>>>> within META-INF/lib.  Classloading was simple as it was all the same
>>>>> classloader.
>>>>>
>>>>> Going forward we need to write an actual deployer for Keycloak
>>>>> extensions that allow you to define Keycloak providers within EE
>>>>> jars,
>>>>> ears, etc.  Writing an extension to Keycloak should be as easy as
>>>>> writing a Java EE application.  Extension developers should be
>>>>> able to
>>>>> leverage the entire JBoss/Wildfly platform. Minimally, we also
>>>>> need to
>>>>> begin and commit/rollback a UserTransaction within a Keycloak request
>>>>> flow so that transaction EE and Spring component layers can function.
>>>> +1 for deployer. Maybe we can try to prototype an example, which
>>>> uses stuff like EJB and then see what exactly we need to add?
>>>>
>>>> For UserTransaction, we can maybe have the KeycloakTransaction
>>>> implementation, which will delegate to UserTransaction? Then people
>>>> can optionally enlist it in their provider if they need it :
>>>>
>>>> session.getTransactionManager().enlistAfterCompletion(new
>>>> UserTransactionWrapper());
>>>>
>>>> Then Keycloak will automatically take care of commit/rollback this
>>>> transaction at end of request.
>>> Why wouldn't they just use UserTransaction?
>> In case that KeycloakTransaction is rolled back, then it calls
>> rollback to all the enlisted delegates. So enlisted
>> UserTransactionWrapper will then call UserTransaction.rollback as well.
>>
>> Unless we're going to rewrite our transaction API to use JTA? That
>> will automatically integrate with JPA and infinispan. If people needs
>> to enlist their own transaction, they need to implement
>> javax.transaction.xa.XAResource. This looks slightly more complicated
>> then implement our KeycloakTransaction, but on the other hand, it's a
>> standard.
>>
> I think we can/should have both.  We automatically begin and enlist a
> UserTransactionWrapper into the KeycloakTransactionManager at the
> beginning of a request (in our filter that starts a KeycloakSession).
> If users want something XA then they implement and integration with
> JTA.  If they want something simpler, than use our KeycloakTransactions.

+1 assuming that automatically enlist UserTransaction in each request
won't have any performance (or other) impact.

Marek

>
> Bill

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev