On 19/10/2016 03:28, Tom Hood wrote:
It's unclear if there really is an interop issue. The application
will launch with 7u55 if I don't set the ORBSingletonClass property,
although that isn't how visibroker 5.2.1 was intended to run, so not
setting it worries me.
Our application does call ORB.init(args,props) once at startup and use
that instance throughout the code we have written.
However, visibroker calls ORB.init() all over the idl generated code
and the vb jar itself.
The javap of the vb jar does show some downcasts to its
com.inprise.vbroker.orb.ORBSingleton implementation in a few classes,
but I haven't tracked down if that code could execute in our
application or if the object it tries to downcast originated from
ORB.init(). The simple test of a basic launch and performing some
activities within the application seem to work. Sadly we don't have
any automated tests that exercise our use of CORBA (java client
to/from c++ server).
The idea of mixing ORB implementations worries me, even if only for
the singleton ORB. I'm new to CORBA and the client side of our
application and still a newbie to java as I've been primarily working
on our c++ server.
Do the reasons for the JDK change to ORB.init() apply in our use
case? There's only one application/context and ORB vendor
implementation running in the jvm in production. Do you think
approach #1 might be a reasonably safe workaround without the risk of
hidden interop issues?
I can't tell from this thread if you have tried with JDK 9 or not
(you've mentioned 7u55 a few times).
I ask because in JDK 9 then the java.corba module is not resolved by
default. If your application starts there then it suggests to me that
Visibroker may be carrying its own copy of the org.omg.** (and RMI-IIOP)
classes, in which case the JDK ORB (even singleton ORB) is not in the
picture. Or maybe you've got past this and your JNLP contains:
<j2se version="9+"" java-vm-args="--add-modules=java.corba">
which is the equivalent to the --add-modules command line option.
Another comment is that if there is code calling the no-arg ORB.init and
blinding casting the return to com.inprise.vbroker.orb.ORBSingleton then
it will never work in the scenario where the system-wide singleton ORB
has been initialized by before Visibroker is used. I completely agree
that it would be unusual to mix different ORB implementations in the
same VM but the API has always allowed for that.
On approach #1 then one thing to be aware of is that the application
class loader is not an instance of URLClassLoader in JDK 9. That is an
implementation change that is known to trip up code that has been
hacking into it.
-Alan
