<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 29/04/16 09:43, Marek Posolda wrote:<br>
</div>
<blockquote cite="mid:572310BA.4060904@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix"> Yes, AFAIK we have open JIRA for
this for a long time ago. <br>
<br>
It's the same issue for IdentityProvider (and maybe some others
SPI too) that they bypass "official" way for create provider via
session.getProvider(providerClazz) and hence they are not
registered in KeycloakSession and "close" method is not called
for them.<br>
<br>
The issue is that our SPI is a bit limited IMO and doesn't
support "stateful" providers. The providers are created through
"ProviderFactory.create(KeycloakSession)". So the only available
state of provider ATM is just ProviderFactory + KeycloakSession,
which is sometimes not sufficient. <br>
<br>
<br>
I can see 2 possibilities to address:<br>
<br>
1) Always make the provider implementation "stateless" and
ensure all the state is passed as argument to provider methods.
This is what we already do for some providers (for example all
methods of UserProvider has RealmModel as parameter). So if we
rewrite UserFederation SPI that UserFederationProviderModel will
be passed as argument to all methods of UserFederationProvider,
then it can use "official" way too. <br>
<br>
<br>
2) Improve the SPI, so it can properly support "stateful"
providers. This is more flexible then (1) and I would go this
way long term.<br>
<br>
I am thinking about something like this:<br>
<br>
public interface StatefulProvider<S> extends Provider {<br>
}<br>
<br>
<br>
public class StatefulProviderFactory<T extends
StatefulProvider, S> {<br>
<br>
<span style="color:#20999d;">T </span>create(KeycloakSession
session, S state);<br>
<br>
....... <br>
}<br>
<br>
<br>
and on KEycloakSession new method like this:<br>
<br>
<pre style="background-color:#ffffff;color:#000000;font-family:'DejaVu Sans Mono';font-size:9.0pt;"><<span style="color:#20999d;">S</span>, <span style="color:#20999d;">T </span><span style="color:#000080;font-weight:bold;">extends </span>StatefulProvider<<span style="color:#20999d;">S</span>>> <span style="color:#20999d;">T </span>getProvider(Class<<span style="color:#20999d;">T</span>> providerClazz, String id, <span style="color:#20999d;">S </span>state);</pre>
<br>
The "state" will need to properly implement equals and hashCode,
so the SPI can deal with it and not create another instance of
StatefulProvider if it was called for this KeycloakSession with
same state before.<br>
</div>
</blockquote>
Just adding the example how easily it will work for UserFederation .
The state will be UserFederationProviderModel, so it will be like:<br>
<br>
UserFederationProviderModel providerModel1 = .... // get somehow
from DB<br>
UserFederationProviderModel providerModel2 = .... // get somehow
from DB<br>
<br>
UserFederationProvider ldap1 =
session.getProvider(UserFederationProvider.class, "ldap",
providerModel1);<br>
UserFederationProvider ldap2 =
session.getProvider(UserFederationProvider.class, "ldap",
providerModel2); // Will return different instance then "ldap1" as
it's different state (providerModel) used<br>
UserFederationProvider ldap3 =
session.getProvider(UserFederationProvider.class, "ldap",
providerModel1); // Will return existing "ldap1" as it was already
used in this KeycloakSession with this state<br>
<br>
At the end of session are 2 registered LDAP providers properly
closed.<br>
<br>
Marek<br>
<blockquote cite="mid:572310BA.4060904@redhat.com" type="cite">
<div class="moz-cite-prefix"> <br>
Marek<br>
<br>
<br>
On 29/04/16 08:00, Stian Thorgersen wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com"
type="cite">
<div dir="ltr">Looking at the code for user federation it looks
like user federation provider instances with the same
configuration can be created multiple times for a single
session. Also they are never closed to resources aren't
released.</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>