I created a EAR project and an application Client project using RAD 7.5. Client project has been included as a module in EAR. The client project has Main.java (Standalone class).
RAD7.5 has been configured to use local WAS6.0 test environment. JMS resources have been configured in WAS6.0 test environment and SI bus has already been created in WAS. My final goal is to send a message to SI bus queue using Main.java class. But I am getting the below exception during InitialContext lookup itself.
Exception in RAD7.5 console is below:
Aug 11, 2010 10:07:46 PM com.ibm.ws.naming.util.CommonHelpers
Aug 11, 2010 10:07:47 PM com.ibm.ws.naming.util.CommonHelpers
Aug 11, 2010 10:07:47 PM com.ibm.websphere.naming.WsnInitialContextFactory
Exception in thread "main" javax.naming.ConfigurationException: The property com.ibm.ws.naming.wsn.factory.initial is not set. The most likely cause is that the jar which contains the file com/ibm/websphere/naming/jndiprovider.properties cannot be found by the class loader.
Main.java class snippet is below:
I see, Provider URL value as "iiop://localhost:21005/" in Universal Test Client GUI in RAD. RAD uses the default jdk which comes in RAD v7.5. Please help to troubleshoot what is causing this error?. I googled it, but couldn't find the cause. Thanks
I think your problem is related to classpath. The client application which is trying to do the JNDI lookup is not able to locate the initial context factory class in its classpath. Fix the classpath and you should be all set.
I'm able to access InitialContextFactory in Main.java (Client) class, also Websphere lib files have been included in the class path. So, don't see any classpath issue for InitialContextFactory class. any other clue?
Deepak Pant wrote:I think your problem is related to classpath. The client application which is trying to do the JNDI lookup is not able to locate the initial context factory class in its classpath. Fix the classpath and you should be all set.
I agree. Time ago, I encountered the same problem, I included some jars of WAS runtime (I just don't rember which ) and the issue has been fixed.
By the way, I remember that those jars were not lightweight... moreover, I was not sure that I could redistribuite them with my application, so I gave up
and searched for another solution....