[keycloak-dev] Access datasource from a CLI
Stan Silvert
ssilvert at redhat.com
Thu Oct 22 08:55:44 EDT 2015
On 10/21/2015 3:39 PM, Stian Thorgersen 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.
You're right. I've been working strictly with the app server too many
years.
It's still a JEE container. JPA is part of the JEE spec. In this case
you are just getting it directly from Hibernate.
>
> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/8bda447b/attachment-0001.html
More information about the keycloak-dev
mailing list