JNI/JacORB Interoperability Problem
Paul W. Schleck K3FU
everyone seems to be stumped. Gerald Brose thinks this problem has come
up before, but doesn't recall what the solutions was.).
I am currently using JDK 1.2.2 on Solaris 2.6 (with recommended patches
applied) and JacORB 1.0 Beta 13 (having hand-applied the necessary fixes
that eventually wound up in Beta 14).
I've discovered that applications that use JNI will not work when
invoked using the "jaco" script that comes with JacORB. JNI is the Java
Native Interface, and allows Java programs to call functions in native
libraries, such as those written in C or C++.
I have gotten JacORB to work with other JacORB applications (including
the demo ones provided), so I am reasonably certain everything is set up
right. The contents of my jaco script are as follows:
#!/bin/sh
# call JDK1.2 interpreter with appropriate options
java -native -Xbootclasspath:"/tools/jacorb/classes:/tools/jacorb/classes/jacorb.jar:${JAVAHOME}/jre/lib/rt.jar:${CLASSPATH}" "$@"
where JAVAHOME is correctly set in my environment. For those not
familiar with JacORB (http://www.inf.fu-berlin.de/~brose/jacorb/), this
wrapper script is necessary to have the Java interpreter load the JacORB
CORBA classes, and not those that come with the JDK (as they are out of
date with respect to current CORBA standards, particularly the Java
language mapping).
I have written an application to work with both Remote Method Invocation
(RMI) and JacORB. On the server side, it uses JNI to run native library
functions written in C. It will interact fine with RMI if the client
and server programs are invoked using java and not jaco. It will not
work with RMI or JacORB if client and server programs are invoked using
jaco. Obviously, the client and server programs will not work with
JacORB if they are invoked using java (as the CORBA part will not work).
What happens with JacORB when client and server are invoked using jaco
is an error like the following:
In commonServerImpl: getHostList()
[ POA RootPOA - rid: 0 oid: 00 11 4D 4D 4D 4D 4C 48 16 3F 0A 07 opname: getHostList - invocation: throwable was thrown ]
############################ StackTrace ############################
java.lang.UnsatisfiedLinkError: no getHosts in java.library.path
at java.lang.ClassLoader.loadLibrary(Compiled Code)
at java.lang.Runtime.loadLibrary0(Compiled Code)
at java.lang.System.loadLibrary(Compiled Code)
at my.server.GetHosts.<clinit>(GetHosts.java:11)
at my.server.commonServerImpl.getHostList(Compiled Code)
at my.corba.serverImpl.getHostList(Compiled Code)
at my.corba.serverPOA._invoke(Compiled Code)
at jacorb.poa.RequestProcessor.invokeOperation(Compiled Code)
at jacorb.poa.RequestProcessor.process(Compiled Code)
at jacorb.poa.RequestProcessor.run(Compiled Code)
####################################################################
I get a similar error when I try to use RMI if the server-side program
is invoked using jaco:
java.rmi.ServerError: Error occurred in server thread; nested exception is:
java.lang.UnsatisfiedLinkError: no getHosts in java.library.path
The JNI part of the code is factored out into a common class called
commonServerImpl that is called both by the CORBA serverImpl and the RMI
Servlett, so it is exactly the same code used by both CORBA and RMI.
I've confirmed that LD_LIBRARY_PATH is configured correctly (and again,
it works with RMI if java is used and not jaco; also the correct
java.library.path is returned if I use the System.getProperty()
method).
Has anyone experienced this problem before? What changes were necessary
to the jaco script (such as in rearranging the Xbootclasspath) to get
JacORB applications to interact correctly with JNI? Nothing obvious,
like removing the -native parameter, or adding all of the *.jar files
that came with the JDK (rt.jar, dt.jar, tools.jar) to the Xbootclasspath
parameter, and reordering them in every combination, has worked so far.
--
Paul W. Schleck
psch...@novia.net
http://www.novia.net/~pschleck/ ICQ# 44218003
Finger psch...@novia.net for PGP Public Key
Polar Humenn >
You are lucky. We came into this problem ourselves. Fred Dushin may be
better at explaining this problem.
But I think the synopsis it the following:
The JDK 1.2 has different notions of "system" class path and "user" class
path. So you can set one up with -Xbootclasspath argument (system) and
the user one with the CLASSPATH evironment variable or the -classpath
argument.
Now, internally there is the same notion for JNI libraries!
However, there is no argument structure to direct this from the command
line.
JNI Libraries loaded from your -classpath may be located in your
LD_LIBRARY_PATH
environment variable. However, if the System.loadLibrary() call is in
one of the classes loaded from the -Xbootclasspath, it must be found
in the java "system" library, which is,
$JAVA_HOME/jre/lib/i386 (for linux)
$JAVA_HOME/jre/lib/sparc (for solaris)
I believe there is no other way around this problem.
Somebody please post if there is.
Cheers,
-Polar
--
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:po...@adiron.com 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com