<div dir="ltr">We manage our own EntityManagerFactory and EntityManager as well as our own transactions. So that's not true.</div><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 class="">
<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 class=""><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>