[keycloak-dev] Access datasource from a CLI

[Stian Thorgersen]

We manage our own EntityManagerFactory and EntityManager as well as our own
transactions. So that's not true.

On 21 October 2015 at 19:53, Stan Silvert <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> 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/af0ddbc6/attachment-0001.html