If you would have used Java programs to connect to IBM DB2 v7.2, you have a choice to use JDBC 1.0 or JDBC 2.0. You can use JDBC MetaData API to get the JDBC Driver version.

An excellent resource on history of JDBC can be found at Herong’s website.

Using JDBC2.0 has helped us solve many issues, particularly with some methods used in storing BLOB/ CLOB data.

By default, DB2 v7.2 provides JDBC 1.0 driver files. To use JDBC 2.0, the trick is to run a batch file that comes shipped with DB2 v7.2. Have a look in your “d:\Program Files\SQLLIB\java12″ directory. You will find two batch scripts: useJdbc1.bat & useJdbc2.bat. Now run “useJdbc2.bat” that will replace the driver files to JDBC2.0. While running batch file, you have closed your WSAD or DB2 instances.

There are two steps involved in adding (i.e importing) SSL certificates to Webserver. I assume you are dealing with Java (any version) JVM. It doesn’t matter whether you are using Websphere, Weblogic, or any other J2EE application server, as long as you know the path to the Java home folder.

You can find out Java Home folder by this simple statement: System.getProperty(”java.home”).

Step1: Exporting SSL Certificate from IE6.0

1. IE6: Open the target website e.g. https://www.verisign.com
2. Go to your Internet Explorer option menu “Tools / Options / Content”. Click button.
3. Find certificate with Target Website name.
4. Click button.
5. Select the format as “DER encoded binary x.509 (.CER)”. Save on some location, say c:\

Step2: Use keytool from /bin directory to add the certifcate to TrustStore.

Java SDK comes with lot of tools under its /bin folder. Note: you need Java SDK & not just JVM installed. The ‘keytool’ program in /bin folder is used to import a SSL certificate to Java’s TrustStore.

For Windows,
keytool -keystore cacerts -storepass changeit -import -alias -file

.cer -trustcacertsFor Unix/ Linux
bash-2.05# ./keytool -import -file /tmp/.cer -keystore /jre/lib/security/cacerts -alias -trustcacerts

How does it work?
When URL connection class connects to a secure website (usually with https:// prefix), the Webserver would send SSL certificate to prove that it is indeed the one which you tried to connect. Now URL connection is hardwired (actually its another class called TrustManager) with logic to validate the SSL Certificate against the default factory TrustStore. The TrustStore usually lies in “jre/lib/security/cacerts” file. If the website’s SSL certificate is not valid, then URL connection class would throw a SSL Handshake Exception. So it’s important to add target website’s SSL certificate to the TrustStore.

To my query on creating a Custom TrustManager in Websphere, I got a reply. It talks about alternative way to trick your code into trusting the SSL certificate. Instead this solution below talks about using custom Truststore & configuring your server to check Truststore to validate web servers SSL certificates.
Assuming that you are doing plain HTTPS, first procure the server’s HTTPS certificate.

Next, you need to create a custom truststore that contains the server’s certificate. You can do this using the JDk keytool command:
C:\>keytool -import -file -alias

-keystore You will be prompted for a password that will be eventually used to protect the truststore.Once you have created the truststore, you need to tell your client’s JVM that you want to use that truststore. You can do that by specifying the following system properties:
javax.net.ssl.trustStore
javax.net.ssl.trustStorePassword.

For example you might use the following java command to run your client:
C:/>java -Djavax.net.ssl.trustStore=mytruststore.jks -Djavax.net.ssl.trustStorePassword=secret my.main.Class

There is a 3rd solution to this problem, which is importing the web servers SSL certificate into your JVM’s /jre/lib/security/cacerts’ file which I will discuss in future post. But sometimes, this approach may not be possible due to security implications & limited access owing to company policies & shared servers.

I am facing an issue with SSL connection in Java, I hope below query makes it clear. I haven’t got any reply from anyone as of yet. Appreciate if someone help me to solve the problem.

If I do find any solution, I would post it here.

My program involves connecting to HTTPS website using java.net.URL class. I am using Websphere 5.1.2 with JVM 1.4.1. So typically I would do,

URL abc = new URL(https://verisign.com);

abc.openConnection(…);

However, I get below exception.

javax.net.ssl.SSLHandshakeException: unknown certificate

With some research I found, I will have to add the SSL Webserver Certificate to JVM’s ‘cacerts’ file. But, I can’t add certificates due to client limited access.

The other way, will be to create a custom ‘TrustManager’ class that would ‘trust’ all certificates by default.

SSLContext sc = SSLContext.getInstance(“SSL”);

sc.init(null, trustAllCerts, null); ‘trustAllCerts‘ -> this will be my all trusting TrustManager

HttpsURLConnection.setDefaultSSLSocketFactory(

sc.getSocketFactory());

Though, this works for a standalone Java exception, but think Websphere needs something else.

Can anyone help me with configuring a custom TrustManager to Websphere 5.1.2? Thanks.

References:

• Guide to JSSE, differences between JDK 1,2, 1.3 & 1.4
• Other questions and solutions about untrusted certificate
• http://forum.java.sun.com/thread.jspa?threadID=515154&messageID=2453574
• Trust manager control of X.509 certificate trust decisions
• Example: Developing a custom trust manager for custom SSL trust decisions
• ssl.client.props client configuration file
• Discussion on issues with Custom TrustManager on Websphere
• Deep understanding of the internals of the java.net.URL architecture
• Sample code to open a https connection in Java using JSSE

Ever tried to port your Struts application on WAS 5.1.2 (Websphere Application Server). I got below with JAXP. JAXP is industry standard J2EE lib for parsing XML files. The Parser implementation can be configured via system.property or thro’ jaxp.properties file on your server path. This is an advantage, so that you can change the XML Parser implementation without requiring to change your application code.

In this case, JAXP wasn’t able to create factory class: SAXParserFactory.

[6/20/08 12:08:29:770 IST] 48696308 SystemErr     R Jun 20, 2008 12:08:29 PM org.apache.struts.action.ActionServlet init
SEVERE: Unable to initialize Struts ActionServlet due to an unexpected exception or error thrown, so marking the servlet as unavailable.  Most likely, this is due to an incorrect or missing library dependency.
javax.xml.parsers.FactoryConfigurationError: Provider null could not be instantiated: java.lang.NullPointerException
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:141)

Solution:

Step1: Locate jaxp.properties file in your Websphere server JVM path. In my case, it was:

D:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\runtimes\base_v51\java\jre\lib

Step2: Un-comment the following lines:

#javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl
#javax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
#javax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

Step3: Make sure you have the xerces & xercesImpl jar files in your classpath. You can copy xerces & xercesImpl jar to your WEB-INF/lib directory.

You must know that whenever you open WSAD IDE, a .lock file is created under the .metadata directory. This .lock file prevents other WSAD instances from using the same workspace. Why would WSAD do such thing? Well- I don’t know; but the only reason I can think of is- it doesn’t make sense to open two instances of WSAD to open the same workspace.

Okay- whatever this .lock file means, it sometimes creates weird problems you can’t even think of! Believe me, it took me 1 day to figure out why my colleague’s WSAD refused to start! It happened one day, my colleague moved to different city & started configuring the workspace. After installing WSAD, we tried to load the workspace, it flashed alert box; I clicked ‘okay’ & nothing happened.

Now- first thing what I though was may be it’s some licensing issue. I checked with my help desk & they confirmed license is good. It was so weird! I tried to inspect the .log file in the metadata directory. .log file is the one which WSAD writes into any debugging sysouts. But strange thing is the .log file wasn’t getting updated. After scratching head, someone told that there’s already a .lock file created in the .metadata directory. & that’s the reason WSAD refused to start.

Solution? delete that .lock file & you are done. See! WSAD started!

Below is dump of error message that I received while working on my Websphere Server. Here the issue was the my Windows machine virtual memory was too low.

Many of us may not know this, but WSAD (Websphere Studio Application Developer) allows us to specify what all comments need to be generated for methods, classes. For e.g. I often used WSAD’s this inbuilt feature to set the comments generated whenever a new class is created. WSAD allows me to export this setting in a xml file which can then be imported by other developers. This helps (forces) other developers working to write comments as well. To set the code comments to be generated, in your WSAD, go to - Windows -> Preferences -> Java -> Code Generation.

For e.g. When a new class is generated, I give comment as -

The ${user} is replaced by the developers account name on windows machine. And ${date} is replaced by the current date and time.

I typically use Websphere Studio Application Developer (WSAD) which is an Integrated Development Environment for developing professional J2EE applications. The licenses for using WSAD is in lakhs, but I got a chance to work with company that had the license. WSAD also comes with Websphere Application Server (WAS) so that you can develop and run the J2EE application instantly.

Problem: Developement cycle is typically code, start server, test, re-code, re-start server…the problem is whenever you start the WAS, it generates log files. So if you happen to run the server 100 times in a month, you end up with 100 log files. Now these loog files are typically 3-4 MB per log file which in turn slows down the server.

Solution: I usually delete the log file periodically. For this,

1. I open up comman prompt on Windows - CMD.
2. Go to your workspace directory and
3. execute command Del /S server*.txt

Now, when you start the server, it’ll start in just 30 seconds!