<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 10/21/2015 10:43 AM, Marko Strukelj
      wrote:<br>
    </div>
    <blockquote
cite="mid:CA+1OW+hYin+KxbZLHhGbW=uQQKp0bJCj5chmRC4HMyGmF_CXZQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">Since Wildfly's config is persisted into a single
        standalone.xml file, the offline mode can be achieved simply by
        editing that file. It would bypass all MDR model checks as
        defined by services, so it's up to our console to not generate a
        corrupt config, which may mean it would have to contain
        subsystem version specific information. But that would only be
        necessary for subsystems that we would touch.
        <div><br>
        </div>
        <div>We might try with Wildfly Swarm to boot a programatically
          configured bare minimum to get datasources / mongo / ldap
          connectors and use them directly.</div>
      </div>
    </blockquote>
    I don't see how that helps you use datasources directly.  From what
    I understand of Swarm, it's just a different way to start the same
    containers.  But you still have the problem of accessing from
    outside the container.<br>
    <br>
    Or, you need something akin to Bill's SSH solution where the WAR
    actually kicks off the CLI.   (At one point Bill was proposing that
    our WAR expose a port that someone could SSH into and issue
    commands.  But that was eventually rejected.)<br>
    <blockquote
cite="mid:CA+1OW+hYin+KxbZLHhGbW=uQQKp0bJCj5chmRC4HMyGmF_CXZQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>But any such approach would not build on jboss-cli, and
          would have to start with some other console as a base, maybe
          something like CraSH (<a moz-do-not-send="true"
            href="http://www.crashub.org/">http://www.crashub.org/</a>).</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Oct 21, 2015 at 4:05 PM, Stan
          Silvert <span dir="ltr">&lt;<a moz-do-not-send="true"
              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 class="HOEnZb">
              <div class="h5">On 10/21/2015 8:59 AM, Stian Thorgersen
                wrote:<br>
                &gt; It would be nice to have an "offline" cli that can
                be used to<br>
                &gt; configure Keycloak. If we roll our own CLI for that
                and it uses<br>
                &gt; jboss-modules do you reckon we can get access to
                the datasources<br>
                &gt; somehow? This is for things like setting the admin
                password,<br>
                &gt; import/export from cli, etc..<br>
              </div>
            </div>
            That's what WildFly's "offline CLI" feature was built for:<br>
            <a moz-do-not-send="true"
              href="http://wildfly.org/news/2015/03/13/Offline-CLI/"
              rel="noreferrer" target="_blank">http://wildfly.org/news/2015/03/13/Offline-CLI/</a><br>
            <br>
            Of course, anything is possible, but doing this ourselves
            involves more<br>
            than just using jboss-modules.  You have to start up the
            environment<br>
            that lets you use whatever technology you are choosing to
            connect to the<br>
            data.   If we want to reuse our current code for that then
            it means<br>
            starting container environments such as CDI, JPA, and other<br>
            dependencies, then wiring them together and starting our own<br>
            stripped-down version of the overall server.<br>
            <br>
            Probably, we would end up doing exactly what WildFly CLI
            does and just<br>
            embed the server into our CLI process.<br>
            <br>
            Then we are back to the problem of actually getting access
            to the<br>
            datasource.  That's really a problem whether we roll our own
            or not.  In<br>
            embedded mode, you can't use the REST API because no inbound
            connections<br>
            are allowed.<br>
            <br>
            Any CLI will run outside the container.  So you are always
            faced with<br>
            accessing the container context from outside the container,
            which is<br>
            next to impossible.  This is the land of the
            java.lang.LinkageError.  So<br>
            you need some way to call into the container using a
            serialized data<br>
            format.  If there is a way to do in-process, port-less REST
            calls then<br>
            that's probably the easiest solution.  But I'm really
            grasping at straws<br>
            here.  I'd have to do some research to find out what our
            options are.<br>
            _______________________________________________<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/mailman/listinfo/keycloak-dev</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>