I am having a similar problem. I followed the advice above, but didn't get good results.
I am using Netbeans 6.5 to create my program. I run the java class via the command line given with the Netbeans compile, but I first place the jndi.properties file in the dist directory. The jndi.properties file has two properties in it.
Running the test program returns results as follows:
Dec 31, 2008 10:27:05 AM com.company.utils.darnCodeThatIsntWorking.NonWorkingCode listJndiProperties SEVERE: NamingException in listJndiProperties(). javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(Unknown Source) at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source) at javax.naming.InitialContext.getEnvironment(Unknown Source) at com.company.utils.darnCodeThatIsntWorking.NonWorkingCode.listJndiProperties(NonWorkingCode.java:180) at com.company.utils.darnCodeThatIsntWorking.NonWorkingCode.<init>(NonWorkingCode.java:148) at com.company.utils.darnCodeThatIsntWorking.NonWorkingCode.main(NonWorkingCode.java:163)
The directory that contains the jndi.properties file should be in the classpath. For example:
the classpath should be: lib/sth.jar ther (assuming you are in app, if windows is your os the separator is ; not
The directory trick is the same as if you added non-packaged class files - in this case you simply add the directory that contains the class files. [ December 31, 2008: Message edited by: Raf Szczypiorski ]
Joined: Dec 13, 2007
I really appreciate the information and advice. I am doing what I can to make this work as you have said.
OK. I am really a greenhorn at this. I created a project in NetBeans early last year which required the jndi.properties. That project has the classpath set somehow to see the jndi.properties. I cannot figure out for the life of me how that NB project sets up the classpath and this new one doesn't. I will continue comparing projects and build files, but this really has me stumped.
I realize this is a two pronged problem - one of finding the jndi.properties file and the other is setting NetBeans up to provide the classpath information. I appreciate your patience as I work with the two.
Joined: Aug 21, 2008
To check / modify the classpath, do this:
1. Right-click on the project in question
2. A new window appears, that has a tree widget at the left side
3. Click on "Libraries", you will see a panel with 4 tabs: "Compile", "Run", "Compile Tests", "Run Tests"
4. Click on the one that you need to check out / modify (I will use "Compile", it is propagated to all of the other ones)
5. There should be a list of jar files and folders that are parts of your classpath
6. If the directory that contains your jndi.properties is not listed, add it clicking the "Add JAR / Folder", browse you filesystem and add it. Remember it must be the directory that contains the file, not the file itself, as you would do with JAR files.
7. Check if the project contains any stale classpath entries - for instance, the filesystem (and the paths to jars and jndi.properties) may have changed or it may be a completely different machine. Delete / edit such entries and provide correct paths.
That should do it.
Note: I was using NetBeans 6.1, there are newer versions and I don't know which one you use, but it should be at least very similar to my version anyways.
Joined: Dec 13, 2007
Thank you. I did that. It doesn't appear to help. The other project I have that works doesn't have the classpath setup in that way for it to work. As a test I put my jndi.Properties list display code in the working project and it lists out just fine. (Just another indication that the problem is having the InitialContext read the jndi.Properties file.).
On a side note I noticed something very interesting when I added the Folder to the classpath. The problem comes that in the 'dist' directory the 'lib' directory that is normally created to hold the two persistence unit project jar files is no longer created and does not have the persistence unit jars copied to it. This renders the project completely useless.