[keycloak-dev] Access datasource from a CLI

[Stan Silvert]

On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
> We manage our own EntityManagerFactory and EntityManager as well as 
> our own transactions. So that's not true.
If all you need is the datasource info that lives in standalone.xml then 
yes, we can get that.

>
> On 21 October 2015 at 19:53, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     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/af6853e4/attachment.html