<div dir="ltr">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.<div><br></div><div>We just need the classes which we can get with jboss-modules.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 October 2015 at 20:16, Stan Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 10/21/2015 2:08 PM, Stan Silvert
wrote:<br>
</div>
<blockquote type="cite">
<div>On 10/21/2015 1:57 PM, Stian
Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">We manage our own EntityManagerFactory and
EntityManager as well as our own transactions. So that's not
true.</div>
</blockquote>
If all you need is the datasource info that lives in
standalone.xml then yes, we can get that.<br>
</blockquote></span>
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.<br>
<blockquote type="cite"><span class=""> <br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at 19:53, Stan
Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<div>On 10/21/2015 1:23 PM, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Guys - all we need is the datasource.
I want to create a "db tool" for Keycloak, this is
not for the Admin CLI
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>If offline mode can do this then that'd be
good, but I seem to remember datasources weren't
available?</div>
</div>
</blockquote>
</span> 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.<br>
<br>
Hey, let's just use JDBC! :-)<span><br>
<br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at
18:22, Marko Strukelj <span dir="ltr"><<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span>On Wed, Oct
21, 2015 at 5:57 PM, Stan Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On
10/21/2015 11:14 AM, Marko
Strukelj wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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 ...<br>
</blockquote>
</span> 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.<br>
<br>
Here is an explanation of the
problem based on an old version of
JBoss:<br>
<a href="https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html" rel="noreferrer" target="_blank">https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html</a><br>
<br>
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.</blockquote>
<div> </div>
</span>
<div>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.</div>
<span>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
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.<br>
</blockquote>
</span> 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.<br>
<br>
Or, as I mentioned, you need the CLI
to actually live inside the
container.</blockquote>
<div><br>
</div>
</span>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
</span><span class=""><pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>