[keycloak-dev] Access datasource from a CLI

[Stan Silvert]

On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
> 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?
If you want to use our existing JPA infrastructure then you need a JPA 
container.  That's where this other stuff all gets pulled in.

Hey, let's just use JDBC!  :-)

>
> On 21 October 2015 at 18:22, Marko Strukelj <mstrukel at redhat.com 
> <mailto:mstrukel at redhat.com>> wrote:
>
>     On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert <ssilvert at redhat.com
>     <mailto: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/67550bd1/attachment.html