<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class="">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><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><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 class=""><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><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>