Stephan van Hulst wrote:It's always a bad idea to use a global classpath. You should specify the classpath per project, using either command line options, or project settings when you're using an IDE.
Your current problem is caused by the fact that jars aren't picked up when the classpath points to a folder that contains them. You need to point the classpath to each individual jar file, or put the jar files in the lib/ext folder of your virtual machine.
Stephan van Hulst wrote:
... or put the jar files in the lib/ext folder of your virtual machine.
AhFai Chan wrote:
I have downloaded Oracle's latest jodbc6.jar and my CLASSPATH points to c:\Program Files\Java\jdk1.7.0_40\lib
Tim Holloway wrote:
If you define a CLASSPATH environment variable for Tomcat, for example, that's not going to help, since Tomcat builds its internal classpaths from the Tomcat lib directory, the WEB-INF subdirectories of deployed webapps, and other pre-defined places.
J. Kevin Robbins wrote:Thanks, very interesting info.
And we are in the process of migrating. I have the virtual machine file for our new web server. I plan to install it over the Christmas break and start testing. Java 8, Tomcat 8, MariaDB, all the fun toys...
Tim Holloway wrote:I have become somewhat of a container maniac. In fact, I've done a number of container projects for clients over the last 2 years give or take.
Tim Holloway wrote:
Despite all the abuse that Java has taken in the security arena in recent times, Java was, in fact, designed from Day 1 to be secure. One of the things that was done to ensure that security was that mechanisms exists to keep people from just dropping classes into the JRE's core classpath. Only resources that have been properly authorized will be recognized.
No matter how many women are assigned to the project, a pregnancy takes nine months. Much longer than this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)https://products.aspose.com/total/java