<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>FYI, deployer is now in master if you didn't see the email. It
does not support deploying SPIs though. I'm not sure on the
implications of supporting that or if it can even work with hot
re-deployment. i.e. a different deployment that implements that
deployed SPI.<br>
</p>
<br>
<div class="moz-cite-prefix">On 8/15/16 7:39 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeq_rKjcUHwodjtO89j-sZBO92Mrcw9uAtqBOG0JGCKpA@mail.gmail.com"
type="cite">
<div dir="ltr">+1 To dropping provider directory as it's not very
useful for real providers.
<div><br>
</div>
<div>Deployer would be awesome, especially if we can leverage
jboss-deployment-structure.xml as an alternative to modules
and Maven deploy plugin. Sounds like a lot of work though.
There's also the issue around not supporting applications
deployed directly to Keycloak.</div>
<div><br>
</div>
<div>For a long time ago I built a server which used regular old
JEE session beans as plugins. All you needed to to was to
register it globally in JNDI and the server would scan for
implementations of specific classes. It was a bit of a pain
when it came to life cycle (beans would need to be deployed
before the server, etc.). Worked quite well though ;)</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 5 August 2016 at 10:36, Marek
Posolda <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 04/08/16 16:03, Bill Burke wrote:<br>
><br>
><br>
> On 8/4/16 9:56 AM, Marek Posolda wrote:<br>
>> Yep, so we can address this with some sort of
"deployer" you<br>
>> proposed, which will have automatically access to
JEE APIs, so people<br>
>> won't need to declare dependencies on them
anywhere? Still people<br>
>> always need to deal with modules though, if they
don't want just JEE,<br>
>> but also some other different 3rd party
dependencies...<br>
> True, but at least we can make a keycloak deployer
that is consistent<br>
> with WARs, etc. Meaning, those that are experienced
writing WARs in<br>
> Wildfly and using jboss-deployment-structure.xml will
not have to be<br>
> completely retrained to write a keycloak component.<br>
</span>+1<br>
<div>
<div class="h5">><br>
>><br>
>>>>> * Had to use JpaKeycloakTransaction
to enlist EntityManager with<br>
>>>>> keycloak transactions. This means
using EJBs is out of the question.<br>
>>>>><br>
>>>>> This is unacceptable. Keycloak is
supposed to be simple and this is<br>
>>>>> extremely difficult. When Keycloak
was an exploded WAR you could use<br>
>>>>> every Java EE component type as you
could just plop your extensions<br>
>>>>> within META-INF/lib. Classloading
was simple as it was all the same<br>
>>>>> classloader.<br>
>>>>><br>
>>>>> Going forward we need to write an
actual deployer for Keycloak<br>
>>>>> extensions that allow you to define
Keycloak providers within EE<br>
>>>>> jars,<br>
>>>>> ears, etc. Writing an extension to
Keycloak should be as easy as<br>
>>>>> writing a Java EE application.
Extension developers should be<br>
>>>>> able to<br>
>>>>> leverage the entire JBoss/Wildfly
platform. Minimally, we also<br>
>>>>> need to<br>
>>>>> begin and commit/rollback a
UserTransaction within a Keycloak request<br>
>>>>> flow so that transaction EE and
Spring component layers can function.<br>
>>>> +1 for deployer. Maybe we can try to
prototype an example, which<br>
>>>> uses stuff like EJB and then see what
exactly we need to add?<br>
>>>><br>
>>>> For UserTransaction, we can maybe have
the KeycloakTransaction<br>
>>>> implementation, which will delegate to
UserTransaction? Then people<br>
>>>> can optionally enlist it in their
provider if they need it :<br>
>>>><br>
>>>> session.getTransactionManager(<wbr>).enlistAfterCompletion(new<br>
>>>> UserTransactionWrapper());<br>
>>>><br>
>>>> Then Keycloak will automatically take
care of commit/rollback this<br>
>>>> transaction at end of request.<br>
>>> Why wouldn't they just use UserTransaction?<br>
>> In case that KeycloakTransaction is rolled
back, then it calls<br>
>> rollback to all the enlisted delegates. So
enlisted<br>
>> UserTransactionWrapper will then call
UserTransaction.rollback as well.<br>
>><br>
>> Unless we're going to rewrite our transaction
API to use JTA? That<br>
>> will automatically integrate with JPA and
infinispan. If people needs<br>
>> to enlist their own transaction, they need to
implement<br>
>> javax.transaction.xa.<wbr>XAResource. This
looks slightly more complicated<br>
>> then implement our KeycloakTransaction, but on
the other hand, it's a<br>
>> standard.<br>
>><br>
> I think we can/should have both. We automatically
begin and enlist a<br>
> UserTransactionWrapper into the
KeycloakTransactionManager at the<br>
> beginning of a request (in our filter that starts a
KeycloakSession).<br>
> If users want something XA then they implement and
integration with<br>
> JTA. If they want something simpler, than use our
KeycloakTransactions.<br>
</div>
</div>
+1 assuming that automatically enlist UserTransaction in
each request<br>
won't have any performance (or other) impact.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marek<br>
</font></span>
<div class="HOEnZb">
<div class="h5">><br>
> Bill<br>
<br>
______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>