[keycloak-dev] Access datasource from a CLI

[Stan Silvert]

On 10/21/2015 2:08 PM, Stan Silvert wrote:
> 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.
But I'm a little confused as to how this would work.  Are you saying 
that you wouldn't use any of the classes in 
org.keycloak.models.jpa.entities?  Those need containers.
>
>>
>> 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.
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/7a36cf49/attachment-0001.html