[keycloak-dev] Access datasource from a CLI
Stan Silvert
ssilvert at redhat.com
Wed Oct 21 15:08:40 EDT 2015
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/20151021/6c3fb64f/attachment-0001.html
More information about the keycloak-dev
mailing list