I am migrating a legacy project to a new server. Previously the project used a Oracle DB but now i want it to use Postgress. The queries are simple enough and work the same in Postgres.
However the project is missing a Postgres jdbc-driver. Can i somehow add this dependency sideways to the jar without recompiling?
Can i somehow add this dependency to the jar without recompiling?
It depends.
If you are running the server as java -jar myserver.jar ..., then you will at least need to modify the manifest in the JAR file. Strictly speaking this doesn't entail recompiling, but you do need to explode, modify and repack the JAR file.
If the server uses Class.forName to explicitly load an Oracle Driver class, then you will need to change that code to load the Postgres Driver class instead. (There are other ways to use JDBC that avoid this, but this depends on how your legacy server is implemented.)
If your server uses Oracle specific database classes, or Oracle specific SQL features (or it needs to do the same in the Postgres world) then more extensive changes will be required.
But without actually examining your codebase in detail, we can't predict what is required.
My advice is to replace the Oracle driver JAR with a Postgres driver JAR, and see what happens when you run your server against a Postgres database with the appropriate schemas and data.
But I wouldn't do this "in production". Do it in a test environment. If you can't set up a suitable test environment ... forget it.
And if you don't have the source code for your server, I would forget it too. If anything goes wrong you will most likely need source code to figure out the problem and fix it.
Related
The question that I will ask does not contain any exception or anything. That's where the confusion coming from.
I have been migrating one old legacy application -which connects and writes to Database- to java8. It used to use the db2 library along with the license from /home/db2client/v95fp2/sqllib/java/db2jcc_license_cu.jar:/home/db2client/v95fp2/sqllib/java/db2jcc.jar. And when I check the details of the db2jcc.jar it says IBM DB2 JDBC Universal Driver Architecture.
Now, deleted that library from the classpath and added my new jar under the lib directory of the project db2jcc4-10.5fp11-fp11.jar and deleted the db2jcc_license_cu.jar And when I check the details of the new jar it says IBM Data Server Driver for JDBC and SQLJ. (The reason I changed to the new jar was there was some java8 combability problems in between the old one and java8)
Eventhough I do not have the license and the jars are different, my application still manages to run and write to the database without an exception. This is the reason I am very confused at the moment.
What is the difference between Universal Driver Architecture one and the Data Server Driver for JDBC SQLJ? And why is it still able to run? I have been reading the whole IBM manuals but I still do not know.
I am aware it may not be a type of question that is asked here, but I think that'd help me a lot to understand what's happening.
I've been messing around with Apache Derby inside Eclipse. I've booted up a Network Server, and I've been working with servlets. In my Eclipse project, I have a class called "User", inside the package "base.pack". I have an SQL script open, and I've been trying to convert User, which implements Serializable, into a custom type. When I run the following lines, everything works fine:
CREATE TYPE CARTEBLANCHE.bee
EXTERNAL NAME 'base.pack.User'
LANGUAGE JAVA
This follows the general format they identify here: http://db.apache.org/derby/docs/10.7/ref/rrefsqljcreatetype.html#rrefsqljcreatetype
Now, when I try to create a table using this new type, I get an error. I run the following line:
CREATE TABLE CARTEBLANCHE.TestTabel (ID INTEGER NOT NULL, NAME CARTEBLANCHE.bee, PRIMARY KEY(ID));
And I receive the following error:
The class 'base.pack.User' for column 'NAME' does not exist or is inaccessible. This can happen if the class is not public.
Now, the class is in fact public, and as I noted before, it does implement Serializable. I don't think I'm stating the package name incorrectly, but I could be wrong. I'm wondering, is this an issue with my classpath? If so, how would you suggest I fix this? I admit that I do not know much about the classpath.
Thank you.
(For reference, I have configured my project build path to include derby.jar, derbyclient.jar, derbytools.jar, and derbynet.jar, and I have put these files into my project's lib folder as well).
As politely as I can, may I suggest that if you are uncomfortable with Java's CLASSPATH notion, then writing your own custom data types in Derby is likely to be a challenging project?
In the specific case you describe here, one issue that will arise is that your custom Java code has to be available not only to your client application, but also to the Derby Network Server, which means you will need to be modifying the server's CLASSPATH as well as your application's CLASSPATH.
It's all possible, it's just not a beginner-level project.
To get started with customizing your Derby Network Server, the first topic involves how you are starting it. Here's an overview of the general process: http://db.apache.org/derby/docs/10.11/adminguide/tadmincbdjhhfd.html
Depending on how precisely you are starting the Derby Network Server, you'll possibly be editing the CLASSPATH settting in the startNetworkServer or startNetworkServer.bat script, or you'll be editing the CLASSPATH setting in your own script that you have written to start the server.
If it's a tool like Eclipse or Netbeans which is starting the Derby Network Server, you'll need to dig into the details of that tool to learn more about how to configure its CLASSPATH.
And if you've written a custom Java application to start the Derby Network Server (e.g., as described here: http://db.apache.org/derby/docs/10.11/adminguide/tadminconfig814963.html) then you'd be configuring the CLASSPATH of your custom application.
Regardless, as a basic step, you're going to want to be deploying your custom Java extension classes in the Derby Network Server's classpath, which means you'll want to build them into a .jar file and put that .jar file somewhere that the Derby Network Server has access to, and you'll want to make that build-a-jar-and-copy-it-to-the-right-location process straightforward, so you should integrate it into whatever build tool you're using (Apache Ant?).
And, you'll need to consider Java security policy, because the default security policy will prevent you from trivially loading custom Java classes into your Derby Network Server as that would seem like a malware attack and the Derby Network Server is going to try to prevent that. So study this section of the Security manual: http://db.apache.org/derby/docs/10.11/security/tsecnetservrun.html
I've been developing OSGi modules but so far I've come across a number of issues when I've had to wrap existing jars. An example of this is the use of the Oracle database driver which, even though I've wrapped the jar as bundle, just refuses to work (cannot find the driver class even though its present). This is just a single example but I've had issues with other 3rd party libraries and was wondering if there's a best practice approach to using 3rd party libraries which works every time?
Jlove
The problem in your case is that jdbc uses a class from the java runtime to find the database driver (DriverManager.getConnection). This can not work as the database driver is not accessible from the system classloader (that loaded the DriverManager class).
A way that works in OSGi is to use a DataSource instead: http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html . There you simply create the data source using new and this of course works. The problem is that it makes your user bundle depend on the specific DB driver. So the best practice is to create the DataSource centrally and publish it as service.
You can find some more details in my Apache Karaf DB Tutorial (http://www.liquid-reality.de/display/liquid/2012/01/13/Apache+Karaf+Tutorial+Part+6+-+Database+Access).
Btw. In general this kind of factories are tpyically where libraries fail in OSGi. Every lib invents another and different factory system and most of the are incompatible with the restricted classloaders of OSGi. Luckily most libs are made OSGi ready nowadays. Most times this simply means that you can also call the factory with a concrete object that you can retrieve using an OSGi service.
My preferred approach is not to wrap the library, but to unjar it, add a manifest, and re-jar it. Jars-inside-jars tend to cause issues that are hard to debug. Unjar and re-jar can be automated with a simple ant script.
Also, I like to write MANIFEST.MF manually. If the library being wrapped is small, then it's easy enough to do that. Tools like bnd that generate MANIFEST.MF for you do not always give the right results, and if you rely on them too much you don't know what is going on under the hood.
I have a single .war file with my web-application. The root of the problem is that I want to keep one .war file for all customers (which have different environment). For this I should keep different versions of libraries in .war and decide which of them to use while deployment.
For example:
First customer have oracle 10, the second one have oracle 11. I want keep both ojdbc.jar files in my war, and choose which of them to use according to some parameter in properties file.
One solution to solve this problem is writing my own ClassLoader, which will not load useless files(as shown here: https://serverfault.com/questions/317901/tomcat-possible-to-exclude-jars-during-app-deployment).
The problem is that our ClassLoader class should be into "tomcat\lib" directory. This do installation of my application is more complex.
Maybe there are another ways how to solve this problem? It will be great to do it programmatically inside my application, using reflection or something else.
Thanks for help!
IMHO the best practice for the example you give (database driver) is to provide a datasource through tomcat. This implies that the database driver jar needs to be in the global classpath (tomcat/lib). This would also keep your intent to have the same .war file for all customers - when you update this, you only need to provide an identical file for all users.
In the case of a database connection, you'll most likely need a customized database for each customer anyway - providing this as a datasource through tomcat makes it necessary to configure it once (on first installation), but you won't need to worry about it afterwards.
If database drivers are not your only problem, please update your question with more examples of differing environments/jars.
I've got an Oracle 10g database, and I have a third-party jar file(MQ jars). I want to be able to run a trigger in my database that ultimately runs code in store procedure to operate MQ series and sending messages.
. I can't figure out how to specify a classpath for my jar file that will be recognized when I am executing trigger. How can I do this?
You can use loadjava (or dbms_java.loadjava) to load classes or JARs into the database; but for a third party JAR that seems unwieldy. If it's your database then you may be able to set the CLASSPATH to include the external files before starting the database. I don't think your user session CLASSPATH or any other environment variable (for whoever is taking the action that causes the trigger to fire) will ever have any effect, not least for security reasons - you don't want a user to be able to subvert the expected action by substituting their own Java code.