<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/21/2015 1:57 PM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAcuXAS09r3+Txry3epdnpN9rzRb9JzAZMRvCrdTee5m2w@mail.gmail.com"
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>
<br>
<blockquote
cite="mid:CAJgngAcuXAS09r3+Txry3epdnpN9rzRb9JzAZMRvCrdTee5m2w@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at 19:53, Stan
Silvert <span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</body>
</html>