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
[email protected]
https://www.redhat.com/mailman/listinfo/devtools
_______________________________________________
Devtools mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/devtools
