1 Reply Latest reply on Nov 13, 2003 11:57 AM by kbutler

    Simple client jndi lookup, ClassNotFoundException

      I've killed hours on this already!! Is there an answer?

      When I run my simple client against my JBoss server (same machine, diff VMs), using -D to set JNDI properties, everything works.

      Example:
      %JAVA_HOME%\bin\java -cp C:\pathTo\jbossall-client.jar;C:\pathTo\app.jar -Djava.naming.provider.url=jnp://localhost:1099 -Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory my.app.ClientClass

      This works great!!

      Putting a jndi.properties file into my C:\pathTo directory and using

      %JAVA_HOME%\bin\java -cp C:\pathTo\jbossall-client.jar;C:\pathTo\app.jar;C:\pathTo my.app.ClientClass

      ALWAYS RESULTS IN::

      Exception in thread "main" javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory .
      Root exception is java.lang.ClassNotFoundException: org/jnp/interfaces/NamingContextFactory
      at java.lang.Class.forName0(Native Method)
      at java.lang.Class.forName(Unknown Source)
      at com.sun.naming.internal.VersionHelper12.loadClass(Unknown Source)
      at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
      at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
      at javax.naming.InitialContext.init(Unknown Source)
      at javax.naming.InitialContext.(Unknown Source)
      at com.g1440.hasp.util.jms.QueueClient.initComm(QueueClient.java:159)
      at com.g1440.hasp.util.jms.QueueClient.init(QueueClient.java:70)
      at com.g1440.hasp.util.jms.QueueClient.(QueueClient.java:50)

      I get this error even though the CLASSPATH which worked in the first case STAYED THE SAME for the second case. Just the fact of specifying the jndi properties with -D options makes the difference!

      Here is the content of my jndi.properties (which I got from the QuickStart guide):
      ---------------------------------------------------------
      java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
      java.naming.provider.url=jnp://localhost:1099
      java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
      ---------------------------------------------------------

      So I am not sure that the error I am seeing is valid, or if so there is some JRE classloader issue at work here.

      I have tried:
      + defining my classpath as a SYSTEM env var
      + using different JAR combinations of jbossall-client.jar, jnp-client.jar, jboss-j2ee.jar, etc. etc.
      + putting the jbossall-client.jar into %JAVA_HOME%\jre\lib\ext
      + placing my jndi.properties next to my .class inside of my JAR, and various other places (referenced via a CLASSPATH entry pointing to the directory)
      + specifying ClassPath in my Manifest (desperation only - I'm not running as java -jar...)
      + reading the contents of my jndi.properties myself and populating the System.properties with this

      (the last one looks sorta like

      Enumeration resources = ClassLoader.getSystemResources("jndi.properties");
      while (resources.hasMoreElements()) {
      java.net.URL url = (java.net.URL) resources.nextElement();
      try {
      Properties props = new Properties();
      InputStream reader = url.openStream(); // ref so we can release
      props.load(reader);
      reader.close();

      // SLAM INTO SYSTEM PROPS
      mergeTables (System.getProperties(), props);
      } catch (IOException e) {
      // skip this URL
      }

      ....which actually works, but it seems like populating System.properties AFTER the VM has already initialized has zero effect).

      I've even tried figuring out what Sun's InitialContext and ResourceManager classes are doing (inspired my hack) but all to no effect!!!

      I need to be able to run without the -D options in the command line!! (due to a crappy Win tool we're stuck supporting)

      Can anybody help?? Many thanks!!