JDK1.4b3 vs Orbix2000 compatibility problem

We have a problem with JDK 1.4 beta 3 ORB compatibility with Orbix2000 v1.2.1 on Solaris 8. I am hoping that you can shed some light on this for us, as we are not sure where the problem is.

We are getting a marshalling exception (minor code 535: REQUEST_MESSAGE_NOT_CONSUMED) when invoking a method with no parameters on a remote object.

For example:

ERROR : org.omg.CORBA.MARSHAL:vmcid: 0x49540000 minor code: 535 completed:

No

org.omg.CORBA.MARSHAL:vmcid: 0x49540000 minor code: 535 completed: No

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct

orAccessorImpl.java:42)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC

onstructorAccessorImpl.java:30)

at java.lang.reflect.Constructor.newInstance(Constructor.java:277)

at java.lang.Class.newInstance0(Class.java:301)

at java.lang.Class.newInstance(Class.java:254)

at com.sun.corba.se.internal.iiop.messages.ReplyMessage_1_2.getSystemExc

eption(ReplyMessage_1_2.java:93)

at com.sun.corba.se.internal.iiop.ClientResponseImpl.getSystemException(

ClientResponseImpl.java:108)

at com.sun.corba.se.internal.corba.ClientDelegate.invoke(ClientDelegate.

java:302)

at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:460)

at CisList._MOInfoListStub.numObjects(_MOInfoListStub.java:575)

at getOrders.main(getOrders.java:78)

Investigation using the GIOP snoop plugin showed that the JDK ORB adds 12 bytes of

information after the CORBA header but before the parametric information.

These bytes appear to be consumed correctly by O2K when there are

parameters for the operation. However, when no parameters exist, O2K

seems to have a logic error because it expects the input buffer to be

empty after processing the header, but there are still 12 bytes

remaining.

Several workarounds have been attempted, including setting Orbix

properties that are supposed to suppress the throwing of this exception,

but none have made any difference.

The 12 bytes actually appear to be part of the service context list and as

such should be considered part of the GIOP request header. JDK sends two

service contexts: the first is the codeset negotiation and the second is the

ORB type. These are detailed in the OMG standard (13.7.2.5 and 13.6.3.1

respectively).

Using the GIOP snoop plugin, it would appear that Orbix considers the

codeset negotiation as part of the header but the ORB type is considered to

be outside the header (however, the snoop utility may not be representitive

of the Orbix marshaling code).

We have tried to use OpenORB with the same server, and this seems to work fine.

Can you confirm where the problem lies? Is there any way that we can use the JDK ORB?

Thanks,

Victor Veres

[3062 byte] By [vicveres] at [2007-9-26 16:37:16]