<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><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 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"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></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>
> It would be nice to have an "offline" cli that can be used to<br>
> configure Keycloak. If we roll our own CLI for that and it uses<br>
> jboss-modules do you reckon we can get access to the datasources<br>
> somehow? This is for things like setting the admin password,<br>
> import/export from cli, etc..<br>
</div></div>That's what WildFly's "offline CLI" feature was built for:<br>
<a 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 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>