Solaris JMS C api

Question

          Hello,
          I am having some problems using the JMS C api. The
          call to JmsContextCreate is failing with a -3;
          JMS_JVM_ERROR. The url, username, and password are
          correct and I am passing NULL for the jndiFactory
          to use the deafult Weblogic server context factory
          of "weblogic.jndi.WLInitialContextFactory".
          Setup:
          Solaris 8, Weblogic 8.1 sp1, jdk_141_03, c/c++ client
          using the Studio8 compiler with other third party libraries,
          and the JMS C api obtained from:
          http://ftpna2.bea.com/pub/downloads/jmscapi.ZIP
          The c/c++ client compiles, links, and runs. The
          CLASSPATH and JAVA_HOME environment variables
          have been set accordingly with the JMS C api
          classes directory added to the CLASSPATH.
          I have compiled the c/c++ client with the JMSDEBUG
          defined and it produces the following to stdout/stderr:
          There was an error trying to initialize the HPI library.
          Please check your installation, HotSpot does not work correctly
          when installed in the JDK 1.2 Solaris Production Release, or
          with any JDK 1.1.x release.
          Also the c/c++ client produces another log file
          called "ULOG.pid". Inside this log contains the
          following:
          085910.fusion!?proc.23074.12.-2: 12-01-2003: Weblogic Server Version 7.1
          085910.fusion!?proc.23074.12.-2: LIBJMSC_CAT:15: NLS:6: Message not found, catal
          og LIBJMSC_CAT, set 1, num 15
          It looks like the libjmsc.so library, that is part of
          the jmscapi.ZIP file, is conpiled against an older version
          of jdk and Weblogic. Is there a newer version of the jmscapi.ZIP
          package compiled against a new version of jdk and Weblogic?
          Or is there something going wrong.
          Thanks,
          Keith
          

Answer 1

It was caused by the 2nd threads' classloader.
          The 2nd thread uses the bootstrap classloader by default when attached to jvm, which loads the 'core' java classes only, not even extended classes.
          <p>
          This cause JNDI factory initialization failed.
          <p>
          The solution is to set the 2nd thread's context loader as the system class loader using JNI. See java.lang.Thread#setContextLoader and java.lang.ClassLoader#getSystemClassLoader.