[keycloak-dev] Access datasource from a CLI

[Stian Thorgersen]

Guys - all we need is the datasource. I want to create a "db tool" for
Keycloak, this is not for the Admin CLI

We don'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.

If offline mode can do this then that'd be good, but I seem to remember
datasources weren't available?

On 21 October 2015 at 18:22, Marko Strukelj <mstrukel at redhat.com> wrote:

> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>
>>> I haven'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 ...
>>>
>> Classloading constraints are what you usually run up against.  You can't
>> use your own version of a class that was loaded from a different
>> classloader.  I don'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't worked with Swarm either.
>>
>> Here is an explanation of the problem based on an old version of JBoss:
>>
>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html
>>
>> With jboss-modules, it'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.
>
>
> CLI running in the same JVM as Wildfly would get bootstrapped through
> jboss-modules, and would package it's classes as a jboss module. It can
> then deploy additional 'in-container' 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.
>
>
>
>>> 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.
>>>
>> I don'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.
>>
>> Or, as I mentioned, you need the CLI to actually live inside the
>> container.
>
>
> 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.
>
> I don't know what you mean by 'serialized format to issue commands to a
> foreign container', but if it means taking care of UI interaction, CraSH
> looks pretty decent CLI, easy to extend with custom commands.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/9bd65b6f/attachment.html