<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 8 August 2016 at 23:51, Bill Burke <span dir="ltr">&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok,<br>
<br>
New provider deployer exists in master.  You can package components in<br>
any type of deployment.  i.e. within a EAR or WAR. Hot deploy works as<br>
well.  The deployers/ directory and deployment-scanner subsystem is now<br>
back in the server.  Also added JTA transactions.  So, now when a<br>
KeycloakSession is created a new JTA transaction is associated with the<br>
KeycloakTransactionManager.  If there was an existing JTA transactionn,<br>
that transaction is suspended and resumed after the keycloak session<br>
completes.  JTA TransactionManager lookup has an SPI now which you can<br>
enable/disable in keycloaks-server.json.  If no transaciton manager<br>
exists i.e. within the testsuite, JTA is not used at all.<br></blockquote><div><br></div><div>Why is the existing transaction suspended? Should it not just join the existing transaction?</div><div><br></div><div>We should also make sure our JPA stores use the same transaction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I&#39;ll be documenting all this eventually.  Still have some work to do on<br>
the new user federation spi before that though.<br>
<br>
Bill<br>
<br>
______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br>
</blockquote></div><br></div></div>