Develop Reference

Add missing driver to legacy project in production

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.

Derby, Java: Trouble with "CREATE_TYPE" statement

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

JDBC4 and Class.forName

I wrote some code that connects to a PostgreSQL 9.4 DB via its latest JDBC4 driver. My understanding is that JDBC4 no longer needs the boilerplate "Class.forName("org.postgresql.Driver") driver registration line. Thus, I left it out. It worked fine.
I then put the same exact code in a servlet, added the postgreSQL JDBC jar to WebContent/WEB-INF/lib and it failed saying:
java.sql.SQLException: No suitable driver found for jdbc:postgresql://localhost/
When I add the Class.forName line, it then works fine.
Does anyone know why this JDBC4 driver needs Class.forName when put within a doGet() servlet method, but in a basic Java class it doesn't?
Thanks,
TR
edit: Forgot to mention, I'm using Java 7.
Some updates:
It does appear that this is a fairly common issue in Tomcat. I've moved the JAR out of WEB-INF/lib per the suggestions from this, and other posts. Even with it in TOMCAT_HOME/lib I need to use Class.forName(). Sort of odd, I suppose it has something to do with the way Tomcat registers classes.
Found this post which is the exact issue with the mySQL JDBC driver rather than postgreSQL:
When is Class.forName needed when connecting to a database via JDBC in a web app?

Thanks all for the help with this. I found the exact situation and answer in the Tomcat 7 documentation while learning how to setup a JNDI datasource:
http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#DriverManager,_the_service_provider_mechanism_and_memory_leaks
In short, under these circumstances, you need to register the driver using Class.forName even if you are using JDBC4 on Tomcat 7.
Thanks everyone for pointing me in the right direction!
TR

How can I manage library version in .war file before (or during) deploying to tomcat?

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.

JDBC Driver type 1 and 2

Why we cannot use JDBC Type 1 (JDBC-ODBC Bridge driver) and type 2 driver for web application development.
These two drivers requires some client side installation.
I am confused about client ,because when we install all driver specific things in server then what extra things needed for client.

The type I JDBC-ODBC bridge driver is not recommended for production applications. It was a Java 1.0 artifact that allowed immediate interconnection via ODBC for development, nothing more.
Type II JDBC drivers require native code in order to work. It uses the client-side native libraries for your particular relational database. You have to be able to point to those libraries using LD_LIBRARY_PATH or some other environment variable.
You want a type IV JDBC driver, which is 100% pure Java with no client installation needed. All you need is a JAR file in your CLASSPATH.

Why we cannot use JDBC Type 1 (JDBC-ODBC Bridge driver) and type 2 driver for web application development.
There is nothing to prevent anyone from using Type 1 and 2 drivers in a web-application. It is however not recommended (see the third paragraph).
Both Type 1 and Type 2 drivers are not portable across platforms. While this might not appear to be a problem at first glance, it most certainly is. Especially if your unit-tests are run on one platform, and your acceptance testing and production environments are another. Code that appears to succeed on one environment can fail in another.
However, the most important reason for their non-usage in web applications is the presence of native code. Certain failures in native code, will result in JVM crashes, and that is something that is disliked universally. After all, it will result in unnecessary downtime, when a Type 4 driver could have simply dropped the connection and cleaned up after the failure, without affecting the rest of the application.
As far as client-side settings are concerned, usually the client-side installation depends on the type of the driver used. Type 1 drivers actually wrap another database API like ODBC, and hence require the corresponding ODBC driver to setup as well. Type 2 drivers require the DLLs or shared objects to be present in java.library.path, and usually this is done by setting the PATH or LD_LIBRARY_PATH environment variables.