Client JNDI lookup (vs. JBoss), ClassNotFoundEx ception

[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\jboss all-client.jar;C:\p athTo\app.jar
-Djava.naming.pr ovider.url=jnp://localhost:1099
-Djava.naming.fa ctory.initial=o rg.jnp.interfac es.NamingContex tFactory
my.app.ClientCl ass
-----------------------------

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 ClassNotFoundEx ception.

Example command line:
-----------------------------
%JAVA_HOME%\bin \java -cp
C:\pathTo\jboss all-client.jar;C:\p athTo\app.jar;C :\pathTo
my.app.ClientCl ass
-----------------------------
(the jndi.properties file is in the C:\pathTo dir, and it IS getting
picked up - that is, ClassLoader.get SystemResources ("jndi.properti es")
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.No InitialContextE xception:
Cannot instantiate class: org.jnp.interfa ces.NamingConte xtFactory .
Root exception is java.lang.Class NotFoundExcepti on:
org/jnp/interfaces/NamingContextFa ctory
at java.lang.Class .forName0(Nativ e Method)
at java.lang.Class .forName(Unknow n Source)
at com.sun.naming. internal.Versio nHelper12.loadC lass(Unknown Source)
at javax.naming.sp i.NamingManager .getInitialCont ext(Unknown Source)
at javax.naming.In itialContext.ge tDefaultInitCtx (Unknown Source)
at javax.naming.In itialContext.in it(Unknown Source)
at javax.naming.In itialContext.<i nit>(Unknown Source)
at com.g1440.hasp. util.jms.QueueC lient.initComm( QueueClient.jav a:159)
at com.g1440.hasp. util.jms.QueueC lient.init(Queu eClient.java:70 )
at com.g1440.hasp. util.jms.QueueC lient.<init>(Qu eueClient.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.properti es 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 ClassNotFoundEx ception.

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
getSystemClassL oader().getReso urce("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