[keycloak-dev] Access datasource from a CLI
Stan Silvert
ssilvert at redhat.com
Thu Oct 22 09:03:10 EDT 2015
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/744ddb7d/attachment-0001.html
More information about the keycloak-dev
mailing list