Client JNDI lookup (vs. JBoss), ClassNotFoundException

[Kent]

I'm running on Win2000 and JRE 1.4.1....

I've got a small client trying to do get an InitialContext() and talk
to the local JBoss server running on same machine (different VM of
course).

When I run the client using the -D parameters to specify the JNDI
properties, it works fine.

Example command line:
-----------------------------
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.Na mingContextFactory
my.app.ClientClass
-----------------------------

That works fine. When I use the same command line but remove the -D
JNDI properties, and specify these in a jndi.properties file (by
adding to CLASSPATH), I get a ClassNotFoundException.

Example command line:
-----------------------------
%JAVA_HOME%\bin\java -cp
C:\pathTo\jbossall-client.jar;C:\pathTo\app.jar;C:\pathTo
my.app.ClientClass
-----------------------------
(the jndi.properties file is in the C:\pathTo dir, and it IS getting
picked up - that is, ClassLoader.getSystemResources("jndi.properties")
picks it up fine).

NOTE THAT THE CLASSPATH IS THE SAME IN BOTH CASES. THE ONLY DIFFERENCE
is that one uses the -D properties and the other does not.

If I screw up the jndi.properties file so it can't be found, I get a
different error (the "please provide JNDI properties" standard error).
So I really think I have JNDI properties, just the JVM is having
ClassLoader issues.

Here's my stack trace for reference:
-----------------------------
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(U nknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unkn own Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.InitialContext.<init>(Unknown Source)
at com.g1440.hasp.util.jms.QueueClient.initComm(Queue Client.java:159)
at com.g1440.hasp.util.jms.QueueClient.init(QueueClie nt.java:70)
at com.g1440.hasp.util.jms.QueueClient.<init>(QueueCl ient.java:50)
-----------------------------

I've worked this for a while, and can find nothing useful at JBoss,
Sun or otherwise. Perhaps I'm doing something stupid.

I've tried a bunch of things like:
+ 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 (before getting the InitialContext)

At this point it looks like a weird ClassLoader situation.

Anybody see this as well? Thanks -

[Raymond DeCampo]

Kent wrote:

I'm running on Win2000 and JRE 1.4.1....

I've got a small client trying to do get an InitialContext() and talk
to the local JBoss server running on same machine (different VM of
course).

When I run the client using the -D parameters to specify the JNDI
properties, it works fine.

That works fine. When I use the same command line but remove the -D
JNDI properties, and specify these in a jndi.properties file (by
adding to CLASSPATH), I get a ClassNotFoundException.

Kent,

I'm not sure the problem is, but here's some things to try:

1. Pass the contents of your jndi.properties file to the
InitialContext(Hashtable) constructor and see if that works.
2. Try doing a Class.forName() on the offending class as the first thing
in your app. Try it under both scenarios. Print out the result of
getSystemClassLoader().getResource("class/name/here") under both
circumstances.
3. Verify that none of the other jar files in the classpath contain a
jndi.properties file.
4. Verify that a jndi.properties file does not exist in your JRE's
lib/ext directory (or anywhere in your JRE installation).
5. Try running the app from jar with java -jar. Put the jndi.properties
in the jar.

Be sure to let us know what the problem ultimately turned out to be.

HTH,
Ray