<div dir="ltr">It can be JBoss CLI, that&#39;s no problem as long as it works, but if datasources are unavailable in offline mode then it&#39;s not going to help.<div><br></div><div>Parsing the standalone.xml ourselves and extracting the datasource piece seems very brittle, that&#39;s why I was hoping there was some magic way we could get the datasource. Everything else should be easy enough.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 October 2015 at 22:48, Marko Strukelj <span dir="ltr">&lt;<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@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"><p dir="ltr">@Stian, so your original question is then:</p>
<p dir="ltr">Can we have a non jboss-cli CLI that will use hibernate directly, and configure it with datasource info from keycloak-server.json and standalone.xml?</p>
<p dir="ltr">That would involve identifying Datasource jndi lookup name, finding datasource definition for it, identifying the driver used, and jboss-module containing the driver ...</p>
<p dir="ltr">As long as Hibernate is capable of using connection url to autodetect dialect (AFAIK it can do that) it seems to me the answer is yes, that can be done ...<br>
</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Oct 21, 2015 21:39, &quot;Stian Thorgersen&quot; &lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nopes, that&#39;s not the job of EE containers, that&#39;s what Hibernate does. Hibernate does that perfectly well in standalone Java apps as well. As I said we manage our own EntityManagerFactory.<div><br></div><div>Have you looked at KeycloakServer inside the testsuite? You can spin up a perfectly functional KC server with nothing but an embedded Undertow server.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 October 2015 at 21:08, Stan Silvert <span dir="ltr">&lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@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 text="#000000" bgcolor="#FFFFFF"><span>
    <div>On 10/21/2015 2:43 PM, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">I have no idea what you mean about containers. As I
        said we manage our own EntityManagerFactory, etc.. inside
        Keycloak. It doesn&#39;t rely on JEE for that part.</div>
    </blockquote></span>
    Somebody has to process the annotations in
    org.keycloak.models.jpa.entities, do injection, interception, etc. 
    That&#39;s the job of the EE containers.<div><div><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>We just need the classes which we can get with
          jboss-modules.</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 21 October 2015 at 20:16, Stan
          Silvert <span dir="ltr">&lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@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 text="#000000" bgcolor="#FFFFFF"><span>
                <div>On 10/21/2015 2:08 PM, Stan Silvert wrote:<br>
                </div>
                <blockquote type="cite">
                  <div>On 10/21/2015 1:57 PM, Stian Thorgersen wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">We manage our own
                      EntityManagerFactory and EntityManager as well as
                      our own transactions. So that&#39;s not true.</div>
                  </blockquote>
                  If all you need is the datasource info that lives in
                  standalone.xml then yes, we can get that.<br>
                </blockquote>
              </span> But I&#39;m a little confused as to how this would
              work.  Are you saying that you wouldn&#39;t use any of the
              classes in org.keycloak.models.jpa.entities?  Those need
              containers.<br>
              <blockquote type="cite"><span> <br>
                  <blockquote type="cite">
                    <div class="gmail_extra"><br>
                      <div class="gmail_quote">On 21 October 2015 at
                        19:53, Stan Silvert <span dir="ltr">&lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@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 text="#000000" bgcolor="#FFFFFF"><span>
                              <div>On 10/21/2015 1:23 PM, Stian
                                Thorgersen wrote:<br>
                              </div>
                              <blockquote type="cite">
                                <div dir="ltr">Guys - all we need is the
                                  datasource. I want to create a &quot;db
                                  tool&quot; for Keycloak, this is not for
                                  the Admin CLI
                                  <div><br>
                                  </div>
                                  <div>We don&#39;t need CDI, EJB, etc.. All
                                    we need is the datasource, or at
                                    least the connection information for
                                    the datasource + we also need JBoss
                                    modules so we can get the required
                                    classes.</div>
                                  <div><br>
                                  </div>
                                  <div>If offline mode can do this then
                                    that&#39;d be good, but I seem to
                                    remember datasources weren&#39;t
                                    available?</div>
                                </div>
                              </blockquote>
                            </span> If you want to use our existing JPA
                            infrastructure then you need a JPA
                            container.  That&#39;s where this other stuff
                            all gets pulled in.<br>
                            <br>
                            Hey, let&#39;s just use JDBC!  :-)<span><br>
                              <br>
                              <blockquote type="cite">
                                <div class="gmail_extra"><br>
                                  <div class="gmail_quote">On 21 October
                                    2015 at 18:22, Marko Strukelj <span dir="ltr">&lt;<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@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 dir="ltr">
                                        <div class="gmail_extra">
                                          <div class="gmail_quote"><span>On
                                              Wed, Oct 21, 2015 at 5:57
                                              PM, Stan Silvert <span dir="ltr">&lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>&gt;</span>
                                              wrote:<br>
                                              <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On



                                                  10/21/2015 11:14 AM,
                                                  Marko Strukelj wrote:<br>
                                                  <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I
                                                    haven&#39;t taken a very
                                                    close look at Swarm
                                                    yet, but I assumed
                                                    you start Wildfly
                                                    embedded in the same
                                                    JVM as your Main
                                                    class. If that is
                                                    the case, then there
                                                    should be no problem
                                                    communicating with
                                                    any kind of deployed
                                                    component via heap
                                                    directly - just
                                                    lookup some
                                                    singleton ...<br>
                                                  </blockquote>
                                                </span> Classloading
                                                constraints are what you
                                                usually run up against. 
                                                You can&#39;t use your own
                                                version of a class that
                                                was loaded from a
                                                different classloader. 
                                                I don&#39;t think Swarm
                                                helps you get around
                                                that, but just assumes
                                                you will access the WAR
                                                in the usual way through
                                                an HTTP port.  But I
                                                could be wrong as I
                                                haven&#39;t worked with
                                                Swarm either.<br>
                                                <br>
                                                Here is an explanation
                                                of the problem based on
                                                an old version of JBoss:<br>
                                                <a href="https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html" rel="noreferrer" target="_blank">https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html</a><br>
                                                <br>
                                                With jboss-modules, it&#39;s
                                                easier to get around
                                                these problems, but you
                                                still run into the
                                                isolation built into the
                                                container itself,
                                                especially in the case
                                                of a WAR.</blockquote>
                                              <div> </div>
                                            </span>
                                            <div>CLI running in the same
                                              JVM as Wildfly would get
                                              bootstrapped through
                                              jboss-modules, and would
                                              package it&#39;s classes as a
                                              jboss module. It can then
                                              deploy additional
                                              &#39;in-container&#39; logic that
                                              needs actual access to
                                              datasources via many
                                              different mechanisms. It
                                              can be a .jar containing a
                                              SLSB, a .war, a .sar, a
                                              POJO (via pojo subsystem),
                                              it can be a custom
                                              subsystem that gets
                                              installed ... In every of
                                              these cases it can then
                                              have access to resource
                                              objects bound to
                                              java:jboss JNDI space ...
                                              And in every of these
                                              cases it uses shared types
                                              loaded via dependencies on
                                              jboss-modules.</div>
                                            <span>
                                              <div><br>
                                              </div>
                                              <div><br>
                                              </div>
                                              <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
                                                  <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
                                                    If that is not the
                                                    case, then we would
                                                    need some kind of
                                                    interprocess
                                                    communication going.
                                                    With shell the roles
                                                    of who connects
                                                    where could also be
                                                    reversed, and a
                                                    started up Wildfly
                                                    instance could have
                                                    a service connecting
                                                    out to local port
                                                    bound by our CLI
                                                    rather than the
                                                    other way around.<br>
                                                  </blockquote>
                                                </span> I don&#39;t think
                                                the direction of the
                                                connection matters so
                                                much as the fact that
                                                you need a serialized
                                                format to issue commands
                                                to a foreign container.<br>
                                                <br>
                                                Or, as I mentioned, you
                                                need the CLI to actually
                                                live inside the
                                                container.</blockquote>
                                              <div><br>
                                              </div>
                                            </span>
                                            <div>CLI needs to be able to
                                              execute its logic inside
                                              the container in order to
                                              harness the datasources,
                                              but the UI part that takes
                                              care of getting the inputs
                                              and displaying the outputs
                                              - e.g. CraSH, does not
                                              have to be inside the
                                              container. </div>
                                            <div><br>
                                            </div>
                                            <div>I don&#39;t know what you
                                              mean by &#39;serialized format
                                              to issue commands to a
                                              foreign container&#39;, but if
                                              it means taking care of UI
                                              interaction, CraSH looks
                                              pretty decent CLI, easy to
                                              extend with custom
                                              commands. </div>
                                            <div><br>
                                            </div>
                                          </div>
                                        </div>
                                      </div>
                                    </blockquote>
                                  </div>
                                  <br>
                                </div>
                              </blockquote>
                              <br>
                            </span></div>
                        </blockquote>
                      </div>
                      <br>
                    </div>
                  </blockquote>
                  <br>
                  <br>
                  <fieldset></fieldset>
                  <br>
                </span><span>
                  <pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
                </span></blockquote>
              <br>
            </div>
            <br>
            _______________________________________________<br>
            keycloak-dev mailing list<br>
            <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">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>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">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>
</div></div></blockquote></div><br></div>