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(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/rhq-devel _______________________________________________ rhq-devel mailing list rhq-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel

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(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/rhq-devel > > _______________________________________________ > rhq-devel mailing list > rhq-devel(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/rhq-devel

Sorry, that was /client/download.... On Jun 20, 2012, at 12:43 PM, Steven North wrote: > Hello, > > I have another question related to this issue. I stumbled across > using the URL //host:port/client.download to get the CLI ZIP file > without having to log into the RHQ server. Is this a "guaranteed > API" that we can rely on not changing in future versions? > > Thanks in advance, > > Steve > > > On Jun 14, 2012, at 7:14 PM, Steven North wrote: > >> 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(a)lists.fedorahosted.org >>>> https://fedorahosted.org/mailman/listinfo/rhq-devel >>> >>> _______________________________________________ >>> rhq-devel mailing list >>> rhq-devel(a)lists.fedorahosted.org >>> https://fedorahosted.org/mailman/listinfo/rhq-devel >> > > _______________________________________________ > rhq-devel mailing list > rhq-devel(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/rhq-devel _______________________________________________ rhq-devel mailing list rhq-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel

John, Thanks. I understand that you are saying that server and CLI versions must match and no forward/backward compatibility is guaranteed between CLI and server. I was asking if that //host:port/client/download URL was guaranteed going forward to download the CLI ZIP file (that matches the server). Will the URL always be available? If so, we could always download the (right) CLI from the server as part of establishing our connection. Steve On Jun 20, 2012, at 12:58 PM, John Mazzitelli wrote: > That is where the CLI can be downloaded from (this link is found at > the mani Administration page, I forget which , I think its called > Downloads in the Admin page). > > You can be guaranteed that CLI can talk to THAT server that you > downloaded it from. It is nothing more than the CLI build that > matches the version of the RHQ Server. > > It doesn't mean that you are guaranteed that CLI that you pull down > will be able to talk to any future version of the server. Out of > box, that CLI that is bundled with that RHQ Server is guaranteed > to work with that server. > > ----- Original Message ----- >> Sorry, that was /client/download.... >> >> On Jun 20, 2012, at 12:43 PM, Steven North wrote: >> >>> Hello, >>> >>> I have another question related to this issue. I stumbled across >>> using the URL //host:port/client.download to get the CLI ZIP file >>> without having to log into the RHQ server. Is this a "guaranteed >>> API" that we can rely on not changing in future versions? >>> >>> Thanks in advance, >>> >>> Steve >>> >>> >>> On Jun 14, 2012, at 7:14 PM, Steven North wrote: >>> >>>> 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(a)lists.fedorahosted.org >>>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel >>>>> >>>>> _______________________________________________ >>>>> rhq-devel mailing list >>>>> rhq-devel(a)lists.fedorahosted.org >>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel >>>> >>> >>> _______________________________________________ >>> rhq-devel mailing list >>> rhq-devel(a)lists.fedorahosted.org >>> https://fedorahosted.org/mailman/listinfo/rhq-devel >> >> _______________________________________________ >> rhq-devel mailing list >> rhq-devel(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/rhq-devel >> > _______________________________________________ > rhq-devel mailing list > rhq-devel(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/rhq-devel _______________________________________________ rhq-devel mailing list rhq-devel(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel