More RHQ Java Client library problems...

John Mazzitelli mazz at redhat.com
Mon Jun 18 13:58:22 UTC 2012


I wanted to point out some related work I did last week.

https://bugzilla.redhat.com/show_bug.cgi?id=535514

That actually was an old BZ but this thread reminded me that we should implement something like it.

I committed this implemented feature in master. What this now does is fail to connect to the server if the version of the RemoteClient does not match the major/minor/patch version of the server it wants to talk to. This means the CLI and any Java client that uses RemoteClient will need to be the same version as the server.

Note that if you want to turn this off for some reason (perhaps you know what you want to do doesn't require exact version match to work), there is a system property you can set to turn off the version check. The system property "rhq.client.version-check", if not already set, will have a default value of "true", meaning the check will happen. If you explicitly set that to "false", you can bypass the version check. For example, you can set this in your rhq-cli-env.sh to turn this version check off:

RHQ_CLI_ADDITIONAL_JAVA_OPTS=-Drhq.client.version-check="false"

Of course, do this at your own risk :) since "the bundled version is the version that should be used with that server. It is not guaranteed that earlier (or later) Remote Clients will be compatible." as per https://docs.jboss.org/author/display/RHQ/RHQ+CLI+Installation

----- Original Message -----
> Jay,
> 
> Thanks for the reply.
> 
> I suppose I should admit that we were "warned" by
> https://docs.jboss.org/author/display/RHQ/RHQ+CLI+Installation
> 
> In this case a user is upgrading from an RHQ 4.2 server to an RHQ 4.4
> server so they are running two versions in their environment at the
> same time, and I would argue that from a user's perspective it is a
> burden to have to know which version of an RHQ server you are
> talking to so you know which version of the CLI to use.
> 
> But it is the way it is, so we will try to come up with a solution
> that meets our needs.
> 
> Thanks again for the quick reply.
> 
> Steve
> 
> On Jun 14, 2012, at 6:07 PM, Jay Shaughnessy wrote:
> 
> > 
> > Hi Steve,
> > 
> > On 6/14/2012 4:18 PM, Steven North wrote:
> >> Hello,
> >> 
> >> Back in September 2011 I posted about problems moving from RHQ
> >> 4.0.1 to 4.1 and was able to resolve the problem by  stepping up
> >> to the 4.1 JARs to talk to the 4.1 and 4.01 RHQ server.  Well,
> >> now I'm back with problems stepping up to RHQ 4.4 libraries.  In
> >> this case we are trying to talk to both a JON 3.01 (=RHQ 4.2) and
> >> JON 3.1beta (=RHQ 4.4) server.  The RHQ 4.1 libraries worked fine
> >> with the JON 3.01 server but not with the JON 3.1beta server, so
> >> we stepped up to the RHQ 4.4 libraries.  These work with the JON
> >> 3.1beta server but not with JON 3.01(= RHQ 4.2) nor with an RHQ
> >> 4.1 server.
> >> 
> >> Below is the trraceback from trying to connect to either an RHQ
> >> 4.1 or an RHQ 4.2 server using the RHQ 4.4 libraries.
> >> 
> >> Is this a known and purposeful incompatibility or is this
> >> unexpected.  Is there anything we can do about this other than
> >> use different sets of libraries for each RHQ server version (that
> >> differs)
> > This was a purposeful change that unintentionally affected backward
> > compatibility.  We have maintained backward compatibility with
> > existing scripts, meaning the API, but we have not maintained
> > backward compatibility with newer clients talking to older
> > servers.  It would be nice if it worked but it's not an explicit
> > goal of the project.  Only API compatibility is an explicit goal.
> >  The Availability class had some changes to the data types of
> > existing fields, therefore breaking serialization between the old
> > and new version.
> > 
> > This change went in with RHQ 4.4.  Only the 4.4 client will work
> > with a 4.4 server, or a JON 3.1 server.  It is possible, although
> > not confirmed, that an RHQ 4.3 API may work for earlier versions
> > of RHQ and JON 3.0.x.
> >> 
> >> Thanks in advance,
> >> 
> >> Steve
> >> 
> >> 
> >> Caused by: org.jboss.remoting.CannotConnectException: Can not
> >> connect http client invoker.
> >> org.rhq.core.domain.measurement.Availability; incompatible types
> >> for field startTime. Response: OK/200.
> >> 	at
> >> 	org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:348)
> >> 	at
> >> 	org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:137)
> >> 	at
> >> 	org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> >> 	at org.jboss.remoting.Client.invoke(Client.java:1634)
> >> 	at org.jboss.remoting.Client.invoke(Client.java:548)
> >> 	at org.jboss.remoting.Client.invoke(Client.java:536)
> >> 	at
> >> 	org.rhq.enterprise.clientapi.RemoteClientProxy.doInvoke(RemoteClientProxy.java:85)
> >> 	at
> >> 	org.rhq.bindings.client.AbstractRhqFacadeProxy.invoke(AbstractRhqFacadeProxy.java:87)
> >> 	at
> >> 	org.rhq.enterprise.clientapi.RemoteClientProxy.invoke(RemoteClientProxy.java:69)
> >> 	at $Proxy7.getCurrentAvailabilityForResource(Unknown Source)
> >> 	at
> >> 	com.ocsystems.rtiee.util.jon.JonClientSession.isResourceAvailable(JonClientSession.java:4598)
> >> 	... 8 more
> >> Caused by: java.io.InvalidClassException:
> >> org.rhq.core.domain.measurement.Availability; incompatible types
> >> for field startTime
> >> 	at
> >> 	java.io.ObjectStreamClass.matchFields(ObjectStreamClass.java:2205)
> >> 	at
> >> 	java.io.ObjectStreamClass.getReflector(ObjectStreamClass.java:2100)
> >> 	at
> >> 	java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:600)
> >> 	at
> >> 	java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582)
> >> 	at
> >> 	java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
> >> 	at
> >> 	java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
> >> 	at
> >> 	java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
> >> 	at
> >> 	java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
> >> 	at
> >> 	org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:239)
> >> 	at
> >> 	org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)
> >> 	at
> >> 	org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120)
> >> 	at
> >> 	org.jboss.remoting.marshal.http.HTTPUnMarshaller.read(HTTPUnMarshaller.java:69)
> >> 	at
> >> 	org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:516)
> >> 	at
> >> 	org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:307)
> >> 	... 18 more
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list