[Devtools] jmx over jboss remoting client jars

Thomas Mäder tmader at redhat.com
Fri May 20 07:34:25 UTC 2016


Hi Rob,

thanks for that input. Can you point me to some documentation about 
theses labels and what values they can have? I'm trying to prevent a 
case where stuff breaks with each minor update.

Thomas

Am 19.05.2016 um 16:28 schrieb Rob Cernich:
> Hey Thomas,
>
> You can look at the labels for the image.  There should be a 
> JBOSS_PRODUCT label in each image, along with something like 
> JBOSS_EAP_VERSION, JBOSS_DATAGRID_VERSION, etc., which has the version.
>
> You can also look at the image name.  EAP 6.4 images are named:
> jboss-eap-6/eap64  - base product image (i.e. no openshift integration)
> jboss-eap-6/eap64-openshift - OpenShift s2i image (with clustering and 
> all the configuration goodies)
>
> Hope that helps.
> Rob
>
>
> ------------------------------------------------------------------------
>
>     Hi folks,
>
>     as part of a larger effort, I'm trying to establish jmx
>     connections to eap or wildfly servers inside Openshift/CDK. In a
>     prototype version, this all works well. However, I've recently
>     learned that the version of jmx remoting used is tightly coupled
>     with the wildfly/eap version (see here for an indication:
>     https://paste.fedoraproject.org/368295/14636462/)
>     The problem now is to use the exact right remoting-jmx client
>     version for the server running inside the Openshift pod. This has
>     two facets:
>
>      1. How do I know the exact version of the Widlfly or EAP running
>         in the pod
>         Curently, we do some guessing of the version via the template
>         name of the application. Can anyone suggest a generally
>         applicapble and reliable way to find out what server is
>         running inside a pod?
>      2. Where do I get the appropriate client jar for that version
>         With local servers, we work around this problem by
>         dyncamically adding a classloader for the
>         jbossclient(-all).jar in the server runtime. The trouble with
>         Openshift is that we don't really have access to the server
>         runtime. So assuming we know the server version, we have two
>         options:
>          1. Bundle client jars with eclipse or
>          2. get the client jar from the pod via rsync.
>
>     I'd love to hear you guys chime in, since I am a bit lost here.
>
>     /Thomas
>
>     _______________________________________________
>     Devtools mailing list
>     Devtools at redhat.com
>     https://www.redhat.com/mailman/listinfo/devtools
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/devtools/attachments/20160520/22b03ac5/attachment.htm>


More information about the Devtools mailing list