<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 June 2016 at 15:06, 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">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <p><br>
    </p>
    <br>
    <div>On 6/13/16 4:19 AM, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">I&#39;ve never been a fan of how creating user feds
        outside of the session was done. It&#39;s a completely broken
        concept and has several flaws:
        <div><br>
        </div>
        <div>a) KeycloakSession doesn&#39;t manage instances - we have
          issues with both multiple instances being created as well as
          instances not being closed.</div>
        <div>b) The code that requires an instance needs to know how to
          create one</div>
        <div>c) No way to create a custom way to configure/setup - the
          model approach may work for some, but what if a custom
          provider wants to store config differently</div>
        <div><br>
        </div>
        <div>With that in mind this needs to be fix and not monkey
          patched.</div>
        <div><br>
        </div>
        <div>When requesting an instance of a user federation it should
          be:</div>
        <div><br>
        </div>
        <div>session.getProvider(UserFederationProvider.class, String
          instanceId)</div>
        <div><br>
        </div>
      </div>
    </blockquote>
      <br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>That&#39;s it. It would then be up to the factory of figuring
          out how to instantiate it, not the calling code.</div>
      </div>
      <div class="gmail_extra"><br>
      </div>
    </blockquote></span>
    A user fed provider is often a generic thing that can be configured
    multiple times for multiple different stores (i.e. LDAP).  So, the
    model is a must.  We don&#39;t want people configuring fed providers
    within keycloak-server.json<br>
    <br>
    Model will be used by most (all) providers so it needs to be a
    parameter for creation.  This generic getProvider() method on
    KeycloakSession just doesn&#39;t fit for most situations.  Most mappers
    fall into this category too.  I have thought about defining a
    generic ConfigurationModel and datastore that would be used by
    everything (mappers, fed providers, etc.)<br></div></blockquote><div><br></div><div>Yes, I know. Please read the thread me and Marek and when we discussed this. This really has to be sorted out otherwise we&#39;ll continue to have issues with it. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
  </div>

<br>_______________________________________________<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/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div></div>