invalid IIOP IDL repository identifiers

[bonoc]

I think there is a bug in the way that Jboss generates IIOP IDL repository ids. Rmic and Janeva both generate the same repIds but Jboss is using something different. That leads me to believe its a Jboss bug.

For some class Insured...

rmic and janeva both generate the following valid IDL id

RMI:org.foo.Insured:63ACAFEDF0A89F11:9114CF3E9A780A71

jboss outputs the following - notice that the last hex section is off
RMI:org.foo.Insured:63ACAFEDF0A89F11:9114CF3E9A780A71

Has anyone else seen this? If so has it been fixed in 4.0.x?

Thanks,
Chris

Setup
-----------------
* WindowsXP
* Sun1.4.2_05
* JBoss3.2.3
* Janeva invoking JBoss via IIOP

[starksm64]

Try the released 3.2.7 as this contains the same corba base that was used for the j2ee 1.4 interop tests. If that still shows a problem then its likely 4.0.x will as well.

[bonoc]

The overloaded method bug is fixed in 3.2.7 but the repository ids are still invalid.

[reverbel]

rmic and janeva both generate the following valid IDL id

RMI:org.foo.Insured:63ACAFEDF0A89F11:9114CF3E9A780A71

jboss outputs the following - notice that the last hex section is off
RMI:org.foo.Insured:63ACAFEDF0A89F11:9114CF3E9A780A71

I guess there was some cut-and-paste mistake, as both ids above are exactly equal...

Anyway, JBoss contains no code for computing RMI repository ids. It merely calls the method getRMIRepositoryID(Class clz), which is provided by the JDK's implementation of the interface javax.rmi.CORBA.ValueHandler. You're probably seeing a JDK bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4350294

This bug has been fixed in JDK 1.4.0. Are you running JBoss on a pre-1.4 JDK?

[bonoc]

Thanks for the clarifications Francisco. The post was due to a lack of knowledge in the IIOP area. I am using 1.4.2_05 - but maybe Janeva isn't. I will investigate further.

Thanks

[bonoc]

Also,
It was a typo. However, the rmic that I used to generate the same repository id that janeva is using was from the 1.4.2_05 jdk - which is the same JDK that jboss is running against. That doesn't make sense. So Janeva is using the proper one at compile time, but it may be the one that is using the invalid ids at runtime. I just assumed it was jboss since the generated NET proxies from janeva had the "proper" ids in it.

I will keep you posted.