I need to connect to a mysql database via servlet. I understood that it's not enough to add the jar to the project (properties->java build path->add external), but I need also to add the jar to the classpath.
What means that? How to do it? I searched here for answer and didn't find, except the idea to copy-paste the jar to the src directory - that doesn't fix my problem.
My main problem is:
java.lang.ClassNotFoundException: com.mysql.jdbc.Driver
It depends on, which servlet container (== java web server) are you using. It is probably tomcat, but you need to share this information with us. My answer is for tomcat.
On tomcat, your application has somewhere a root directory (for example, /var/lib/tomcat/yourAppName on linux).
Below this directory, there is a lib subdirectory. This directory is already in your classpath, so it is enough to copy the needed jar into it.
There are much more complex solutions (for example, installing jars into the server classpath and into this application-specific lib directory), but these are probably unneeded in your case.
Related
How should I add JAR libraries to a WAR project in Eclipse without facing java.lang.ClassNotFoundException or java.lang.NoClassDefFoundError?
The CLASSPATH environment variable does not seem to work. In some cases we add JAR files to the Build Path property of Eclipse project to make the code compile. We sometimes need to put JAR files inside /WEB-INF/lib folder of the Java EE web application to make the code to run on classes inside that JAR.
I do not exactly understand why CLASSPATH does not work and in which cases we should add JARs to Build Path and when exactly those JARs should be placed in /WEB-INF/lib.
The CLASSPATH environment variable is only used by the java.exe command and even then only when the command is invoked without any of the -cp, -classpath, -jar arguments. The CLASSPATH environment variable is ignored by IDEs like Eclipse, Netbeans and IDEA. See also java.lang.ClassNotFoundException in spite of using CLASSPATH environment variable.
The Build Path is only for libraries which are required to get the project's code to compile. Manually placing JAR in /WEB-INF/lib, or setting the Deployment Assembly, or letting an external build system like Maven place the <dependency> as JAR in /WEB-INF/lib of produced WAR during the build, is only for libraries which are required to get the code to deploy and run on the target environment too. Do note that you're not supposed to create subfolders in /WEB-INF/lib. The JARs have to be placed in the root.
Some libraries are already provided by the target JEE server or servletcontainer, such as JSP, Servlet, EL, etc. So you do not need put JARs of those libraries in /WEB-INF/lib. Moreover, it would only cause classloading trouble. It's sufficient to (indirectly) specify them in Build Path only. In Eclipse, you normally do that by setting the Targeted Runtime accordingly. It will automatically end up in Build Path. You do not need to manually add them to Build Path. See also How do I import the javax.servlet / jakarta.servlet API in my Eclipse project?
Other libraries, usually 3rd party ones like Apache Commons, JDBC drivers and JEE libraries which are not provided by the target servletcontainer (e.g. Tomcat doesn't support many JEE libraries out the box such as JSF, JSTL, CDI, JPA, EJB, etc), need to end up in /WEB-INF/lib. You can just copy and paste the physical JAR files in there. You do not necessarily need to specify it in Build Path. Only perhaps when you already have it as User Library, but you should then use Deployment assembly setting for this instead. See also ClassNotFoundException when using User Libraries in Eclipse build path.
In case you're using Maven, then you need to make absolutely sure that you mark libraries as <scope>provided</scope> if those are already provided by the target runtime, such as JEE, Servlet, EL, etc in case you deploy to WildFly, TomEE, etc. This way they won't end up in /WEB-INF/lib of produced WAR (and potentially cause conflicts with server-bundled libraries), but they will end up in Eclipse's Build Path (and get the project's code to compile). See also How to properly install and configure JSF libraries via Maven?
Those JARs in the build path are referenced for the build (compile) process only. If you export your Web Application they are not included in the final WAR (give it a try).
If you need the JARs at runtime you must place them in WEB-INF/lib or the server classpath. Placing your JARs in the server classpath does only make sense if several WARs share a common code base and have the need to access shared objects (e.g. a Singleton).
If you are using Maven:
Open the project properties, and under Deployment Assembly click Add...
Then select Java Build Path Entries and select Maven Dependencies
Resolved by setting permissions.
Had related issue using PySpark and Oracle jdbc. The error does not state that the file cannot be accessed, just that the class cannot be loaded.
So if anyone still struggles, check the permissions. Some might find it obvious tho'.
I want to give the answer for the folowing link question ClassNotFoundException oracle.jdbc.driver.OracleDriver only in servlet, using Eclipse
Ans: In Myeclipse go to Server-->left click on Myeclipse Tomcat7-->Configure Server Connector-->(Expand)Myeclipse Tomcat7--> Paths-->Prepend to classpath-->Add jar (add oracle14 jar)-->ok
I have a Spring Boot MVC Application which I intend to deploy as WAR file in Tomcat8. I noticed, the WAR contains all dependencies on WEB-INF/lib and WEB-INF/lib-provided folders. I verified that moving all contents of these dependencies folders to <TOMCATDIR>/lib removes the necessity of having those jars in the WEB-INF/lib* folders, so I moved them all. The application is working as expected.
Suppose, I have many WARs that need to be deployed on the same server and most of them have similar dependencies. Having all the JARs in individual applications' library folders seems like a waste of space to me.
My question is, is it a good idea to move all the JARs from individual applications' library to the Tomcat's library? Will it cause me any problems in future? If it will, what sorts of problem am I likely to come across?
It may be pretty basic question. But no luck Googling.
I was going through this URL. Because I had an issue accessing EJBs deployed on JBoss. After following this, it worked. Mainly this line.
jboss-ejb3-client.jar, jboss-aop-jdk50-client.jar, jboss-aspect-jdk50-client.jar and jbossall-client.jar -
all these .jar files are found in client folder of JBoss installation directory
But for a newbie of EJBs like me, this is following the steps without understanding the dependencies. So my question, can we find documentation like this somewhere? How do we know the jars we need to copy to client application classpath?
jbossall-client.jar for JBoss 4.X is enough - it contains all needed libraries.
For JBoss 5.X the story is more difficult - you need to reference in your project only jbossall-client.jar, but inside this JAR there are no actual classes, only MANIFEST file, which lists needed dependencies.
So, on JBoss 5, you need to have jbossall-client.jar added to classpath of your client plus all listed JARs lying next to it. Crazy, isnt't it?
JBoss 7 has sane approach. There is bin\client\jboss-client.jar that contains all dependencies needed by clients.
I would like to know how to upload a WAR file separated from its dependencies.
For example, you upload al the dependecies and leave them in the classpath
then you upload your WAR file without the dependencies packed in it.
When you are testing you servlet this is very useful as you don´t have to upload
a big WAR file with small changes everytime you need to correct something.
The problem is that sometimes it works and some other times it doesn´t.
So is there an official correct way of doing this?
Of course just packing everything into the WAR file does the job.
If your WAR file has dependencies that are outside of it, then you will need to restart Tomcat whenever you update those dependencies: there is no such thing as a CLASSPATH for a WAR file other than what the container builds for you (which will include the stuff in the webapp's WEB-INF/classes and WEB-INF/lib/*.jar, plus all the libraries guaranteed to be available by the container like servlet.jar, etc.).
Tomcat allows you to use a shared lib directory but that doesn't auto-reload when libraries are updated, which is likely to be causing the "inconsistent" behavior that you are observing.
The official correct way of doing this is to upload the whole WAR file: that's what they are for.
So i received a java api from a client and the main code is in main.jar. But the instructions he gave me require me to add these other jars (a.jar, b.jar, etc..) into the classpath whenever I want to use main.jar. These other supporting jars are things like Xerces, jakarta-oro, and a few other publicly available libraries. The problem is i don't know what versions they are, so i'm not sure if there would be issues if i just update the pom.xml file in my app to depend on main.jar and also have dependencies to these other jars as well with the latest versions of them.
Whats the best strategy for using main.jar in my maven application? I'm planning on adding main.jar to our internal maven repository, but what should i do about the xerces, jakarta-oro, and other jars when i dont know what versions they are?
Thanks
If you are lucky the file /META-INF/MANIFEST.MF inside a.jar, b.jar etc. contains an entry "Implementation-Version" or some other useful information which tell you what version they are. If not, you can download the latest release(s) from the project web site and check if they have the same file size as your bundled dependencies.
You may also come to the idea to bundle the dependencies with the main.jar in one big jar, but this may become funny, when you have the dependencies twice in your classpath at some point in the future...
What about just asking the client what version numbers this dependencies have?
If you don't have any information about these third-party libraries, just add them to src/resources/META-INF/lib and commit to SVN. That's the best way, if we're talking about black box approach.