On 10/21/2015 10:43 AM, Marko Strukelj wrote:
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.

We might try with Wildfly Swarm to boot a programatically configured bare minimum to get datasources / mongo / ldap connectors and use them directly.
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.

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.)

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 (http://www.crashub.org/).

On Wed, Oct 21, 2015 at 4:05 PM, Stan Silvert <ssilvert@redhat.com> wrote:
On 10/21/2015 8:59 AM, Stian Thorgersen wrote:
> It would be nice to have an "offline" cli that can be used to
> configure Keycloak. If we roll our own CLI for that and it uses
> jboss-modules do you reckon we can get access to the datasources
> somehow? This is for things like setting the admin password,
> import/export from cli, etc..
That's what WildFly's "offline CLI" feature was built for:
http://wildfly.org/news/2015/03/13/Offline-CLI/

Of course, anything is possible, but doing this ourselves involves more
than just using jboss-modules.  You have to start up the environment
that lets you use whatever technology you are choosing to connect to the
data.   If we want to reuse our current code for that then it means
starting container environments such as CDI, JPA, and other
dependencies, then wiring them together and starting our own
stripped-down version of the overall server.

Probably, we would end up doing exactly what WildFly CLI does and just
embed the server into our CLI process.

Then we are back to the problem of actually getting access to the
datasource.  That's really a problem whether we roll our own or not.  In
embedded mode, you can't use the REST API because no inbound connections
are allowed.

Any CLI will run outside the container.  So you are always faced with
accessing the container context from outside the container, which is
next to impossible.  This is the land of the java.lang.LinkageError.  So
you need some way to call into the container using a serialized data
format.  If there is a way to do in-process, port-less REST calls then
that's probably the easiest solution.  But I'm really grasping at straws
here.  I'd have to do some research to find out what our options are.
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev