I am trying to get my project into a JAR so I can run it as a CLI.
I have two JDBC connectors that I am using, one for MySQL one for PostgreSQL. Both are located in the same directory and work fine if I run them in the IDE.
When I create the JAR the MySQL connector still works fine, however when trying to establish a connection to PostgreSQL the following error appears.
What really irritates me is that the connector seems to be included in the build of the jar.
Both the MySQL connector and PostgreSQL connector are listed in the build.
How can I go about fixing this?
The problem is that all JDBC-4-compliant JDBC drivers contain a file /META-INF/services/java.sql.Driver that lists the java.sql.Driver implementations in the JAR files. This is used by the java.sql.DriverManager to load the available JDBC drivers.
The process you used for merging apparently doesn't merge the different files from the drivers into a single file, so it only has the content of one of the drivers. As a result, the other driver isn't loaded automatically.
Possible solutions:
Don't merge JAR files into a single JAR, but instead use the Class-Path attribute of META-INF/MANIFEST.MF to specify the JARs you use, and execute your program with java -jar your.jar
Make sure META-INF/services/java.sql.Driver is merged correctly (or maybe provide your own), depending on how you merge, there might be an option to configure which files need to be merged
Explicitly load the drivers using Class.forName("com.mysql.cj.jdbc.Driver") and Class.forName("org.postgresql.Driver") (do it for both to prevent problems if order of merging files changes, and the other file wins)
Related
I'm trying to connect to a database using Derby in Java (using NetBeans), bIt i keep getting this error when I try to create a new database:
An error occurred while crating the database java.lang.ClassNotFoundException; org.apache.derby.jdbc.ClientDriver.
I've tried using Derby 10.16.1.1 and Derby 10.14.2.1.
The error message you are seeing suggests that the class org.apache.derby.jdbc.ClientDriver is not being found by the class loader at runtime. This class is necessary for connecting to a Derby database.
There are few possible causes:
The Derby jdbc driver is not in the class path of your project or application.
The version of jdbc driver jar file isn’t correct version for the version of Derby you are using. Please, check versions.
There is a comprehensive derby documentation where you can find more info and step-by-step guide.
In order to add org.apache.derby.jdbc.ClientDriver to your class path you can do few things, depending on your development environment:
If you're using an IDE like Netbeans, you can add the JAR file to the project's build path by IDE UI, for example, that thread explains how to do so.
If you're building your project with a build tool like Maven or Gradle, you can add the JAR file as a dependency in your project's pom.xml file or build.gradle file. You can read more about that approach here and here
If you're running your project from the command line, you can add the jar file to the classpath by specifying it as a command-line argument when running your project's main class. For example, if the jar file is located in /lib/derby-jdbc.jar, the command would be:
java -cp /lib/derby-jdbc.jar YourMainClass
I have a bunch of dependencies, such as JDBC Drivers, from vendors like Oracle, and Microsoft, which are not on a Public Artifact Repository.
Everytime I want those dependencies to be available while running my Play Application in Dev Mode, I have to put those jars in lib folder(within the play project)
Those drivers are supposed to vary from Customer to Customer, and in some phases of the project we need a Oracle one, some other phase, 2 drivers.
Another point is that, we have multiple Play Applications that we use those drivers, and have to manually place them within the lib folder
How can I avoid this??
I need those jars in the classpath for when I am saying from the command line:
sbt run "play-project" -Dhttp.port=9001
Maybe there is some play parameter that I can also pass an additional
classpath.
I am using Play 2.4 and Scala 2.11.7
I think you have two solutions:
Add your specifics jar files in a common folder and reference that one from your build file. You should add some environment properties or some configurable way to allow other people from your team to configure the jars location.
Create a private maven or ivy repository that contains the specific jars. It could be as simple as a http server with the files and the correct directory structure. This allows you to internally distribute the jar file without having people to configure specific folders on their machines.
For the first solution, from SBT documentation, you should just add those jars in your unmanaged classpath, with in your build.sbt file a line like:
unmanagedJars in Compile := (file("/my_common_path") ** "*.jar").classpath
For the second solution, just have a look at sbt's resolver documentation
I am trying to tackle a persistent ClassNotFoundException. We have an application specific jar that calls a shared commons jar, and uses reflection create an object that we specify in an XML file. This is where it fails.
The application specific jar resides in my NSF. The commons jar resides on the server. I wish to keep the jars in the NSF, because I will be replacing them frequently and don't have access to the server directories, even in Unit.
We put the application jar in the same package as the commons and this didn't help. My suspicion is that the server jar cannot find the application jar. The application jar successfully calls the commons jar, so it is working in that direction.
I tried putting a copy of the commons jar in the NSF, and this didn't help. I think it is still running the server jar first. Jars have same name.
My question is: How do I force the Domino Server runtime to use the application's 'commons' jar instead of the server's 'commons' jar? The thinking being that the local commons jar will find the class of the application jar in the same package, and I can get past this exception.
UPDATE: This process runs when run from a jUnit test, and when a main method is created.
The key is going to be identifying if it's failing because of a security exception or just not finding the jar. If it hits a security exception loading the jar, it just gives that ClassNotFoundException. That can be because it's using the same ClassLoader as the XPpages runtime and was the problem I hit with apache.commons.lang.
If a jar is likely to change regularly and you want it from multiple NSFs, but don't have access to the server, the best option is to create an OSGi plugin (aka Extension Library). This will overcome most security exceptions as well as using a different classloader.
Put it in WebContent\lib, then right-click on it and choose Build Path > Add to Build Path. It will then use a different ClassLoader. See the comments on this blog post http://www.intec.co.uk/how-to-add-in-built-java-packages/. The lib folder is added by default in R9. You do need to add it to the build path, then it jumps into a Referenced Libraries folder.
I have a Java applet, it works correctly when executed from eclipe, but I want to export it to a Jar and use it. but when I do that, i get jdbc driver not found, it seems like when exporting, jaybird is not exported.
For exporting I use eclipse export and choose Java/JAR File, in build path i have jaybird mark to export.
Any suggestions? Thanks in advance
Use Fat Jar to build runnable JARs that contain all dependent libs
You are most likely missing the files from the META-INF folder of the Jaybird jar file. These files are required for Jaybird to work. Another possibility is that you are missing one of the required dependencies of Jaybird (connector-api-1.5.jar, for Jaybird 2.2 or mini-j2ee.jar for earlier versions).
Even if you get this to work though, you will most likely experience an error later on, as Jaybird wasn't developed with support for applets in mind, see http://tracker.firebirdsql.org/browse/JDBC-254 and NoClassDefFoundError with jdbc applet
BTW: Why don't you just use the jar as is. IMHO creating fat jars including all your dependencies is ugly and inflexible.
I finally get the answer, I had to sign the jaybird jar also because that jar was doing read/write operation in HDD
By using Eclipse you can simply solve the problem.
By going to Eclipse -> File -> Export -> Runnable JAR file and selecting Extract required libraries into generated JAR option, Eclipse will extract required libraries beside your project and creates the required MANIFEST.MF file for you and then will pack them all together in your JAR file.
I have a library that contains functionality to connect to on oracle database. When I export this library (as a JAR) and use it in the main project, it gives an exception when loading the driver with class.forname. It obviously cannot find the ojdbc driver. I included this driver in the build path and as exported library.
I tested and used the driver directly from the main project, and it work, it connects to oracle db.
Thanks.
The problem is that your driver is a jar file, and when you export the app as a jar file, that driver will be a jar file in a jar file. For that scenario you either need a special classloader or put the driver jar file in the classpath of your main program.
Explore your exportedjar by using WinRar and check if it contains a jar under jar.