[keycloak-dev] Access datasource from a CLI
Stan Silvert
ssilvert at redhat.com
Thu Oct 22 09:31:46 EDT 2015
On 10/22/2015 9:11 AM, Stian Thorgersen wrote:
> If we have to extract connection information from datasources in
> either case we don't really get much benefit of using offline jboss
> cli though?
You are reading standalone.xml in a standard way, which is better than
parsing it ourselves.
Beyond that, I'd have to try it out to see what other benefits there
would be. It could be that it is indeed very easy to get the
datasource itself. Now that my brain is fixed concerning using
Hibernate directly, I'm thinking this might be possible.
Of course, there are lots of benefits beyond the offline CLI use case,
which I've talked about at great length.
>
> On 22 October 2015 at 15:03, Stan Silvert <ssilvert at redhat.com
> <mailto:ssilvert at redhat.com>> wrote:
>
> On 10/22/2015 2:05 AM, Stian Thorgersen wrote:
>> It can be JBoss CLI, that's no problem as long as it works, but
>> if datasources are unavailable in offline mode then it's not
>> going to help.
>>
>> Parsing the standalone.xml ourselves and extracting the
>> datasource piece seems very brittle, that's why I was hoping
>> there was some magic way we could get the datasource. Everything
>> else should be easy enough.
> So if it's WildFly CLI then there is obviously no problem reading
> standalone.xml in a standard way.
>
> The custom commands we create for WildFly CLI can do anything we
> want. So by pulling in Hibernate and using its JPA implementation
> directly, we could do it.
>
>>
>> On 21 October 2015 at 22:48, Marko Strukelj <mstrukel at redhat.com
>> <mailto:mstrukel at redhat.com>> wrote:
>>
>> @Stian, so your original question is then:
>>
>> Can we have a non jboss-cli CLI that will use hibernate
>> directly, and configure it with datasource info from
>> keycloak-server.json and standalone.xml?
>>
>> That would involve identifying Datasource jndi lookup name,
>> finding datasource definition for it, identifying the driver
>> used, and jboss-module containing the driver ...
>>
>> As long as Hibernate is capable of using connection url to
>> autodetect dialect (AFAIK it can do that) it seems to me the
>> answer is yes, that can be done ...
>>
>> On Oct 21, 2015 21:39, "Stian Thorgersen"
>> <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>> Nopes, that's not the job of EE containers, that's what
>> Hibernate does. Hibernate does that perfectly well in
>> standalone Java apps as well. As I said we manage our own
>> EntityManagerFactory.
>>
>> Have you looked at KeycloakServer inside the testsuite?
>> You can spin up a perfectly functional KC server with
>> nothing but an embedded Undertow server.
>>
>> On 21 October 2015 at 21:08, Stan Silvert
>> <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>
>> On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
>>> I have no idea what you mean about containers. As I
>>> said we manage our own EntityManagerFactory, etc..
>>> inside Keycloak. It doesn't rely on JEE for that part.
>> Somebody has to process the annotations in
>> org.keycloak.models.jpa.entities, do injection,
>> interception, etc. That's the job of the EE containers.
>>
>>
>>>
>>> We just need the classes which we can get with
>>> jboss-modules.
>>>
>>> On 21 October 2015 at 20:16, Stan Silvert
>>> <ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
>>> wrote:
>>>
>>> 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 <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> <mailto: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/20151022/adde5f4d/attachment-0001.html
More information about the keycloak-dev
mailing list