On 8/4/16 9:56 AM, Marek Posolda wrote:
Yep, so we can address this with some sort of "deployer"
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.
>>> * 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
>>> 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 :
>> 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
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.