With the advent of DB2 10, IBM dropped its much-maligned Control Center tools in favor of a free version of IBM Data Studio. I started using Data Studio back in April and wrote about some positive first impressions here. But I shouldn’t have blogged so soon.
For occasional use with certain tasks on fast hardware, Data Studio is fine. But if you want to get a lot done quickly, it can really get in the way. It’s just too bloated, too slow, too cumbersome, too slow, too awkward, and too slow. Did I mention that it’s slow?
So I find myself doing even more now with the command line. When I need a GUI tool, I’ve gone back to using a tool I wrote myself, TOAD, and free tools like DbVisualizer and Eclipse DTP.
Data Studio has been around for awhile, and IBM is clearly committed to it. But there remains a lot of room for improvement. Now that Data Studio is the built-in default, I hope IBM gets on that. And quickly.
This “very Monday” brought some unexpected troubles during a new deployment of my app.
My web services code had worked fine in a variety of environments (WebLogic, Tomcat, etc.), but failed in WebSphere 7 fixpack 23 with exceptions like the following:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection#0’: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org/apache/ws/commons/schema/XmlSchemaCollection.read(Lorg/xml/sax/InputSource;)
Since this had the symptoms of a typical classpath problem, I started there. I had to remember that WebSphere’s version of -verbose as a JVM argument is Application server > Java and Process Managerment > Process definition > Java Virtual Machine – Verbose class loading. I also did a quick check to see what I was using in other environments:
This revealed that the obsolete XmlSchemaCollection class came from WebSphere’s old version of org.apache.axis2.jar in …\IBM\WebSphere\AppServer\plugins. In spite of the “plugin” name, WebSphere is hopelessly intertangled with Axis 2, so removing it was not an option. So I preempted WebSphere by providing my own xmlschema-core-2.0.2.jar, and made it a part of my distribution by adding it to the pom.xml:
Finally, I set “Classes loaded with local class loader first (parent last)” in WebSphere’s class loader settings for my app. In some cases, I had to also place xmlschema-core-2.0.2.jar in a shared library folder.
These extra steps are a bit annoying, but I suppose that’s the price paid for using a Java EE container that lags a bit behind on open source frameworks.
Since I work on a few apps that use the DB2 JDBC Type 4 drivers, work-arounds for common issues have become familiar. But when the corrupted DB2 JAR issue resurfaced today, I realized that I had not posted about it. Now is as good a time as any to make up for that neglect…
The problem is that for DB2 LUW versions between 9 and 9.5, IBM published db2jcc.jar files with corrupt classes. In some Java EE environments, the container doesn’t fully scan JARs, so it doesn’t really matter if an unused class is wonky. But many containers do scan, causing exceptions like the following:
SEVERE: Unable to process Jar entry [COM/ibm/db2os390/sqlj/custom/DB2SQLJCustomizer.class] from Jar [jar:file:…lib/db2jcc.jar!/] for annotations
org.apache.tomcat.util.bcel.classfile.ClassFormatException: null is not a Java .class file
That particular exception is from Tomcat 7.
IBM acknowledges the problem (see http://www-01.ibm.com/support/docview.wss?uid=swg1LI72814) and offers a work-around: edit the JAR file to remove the offending classes.
Edit the JAR? Really?! A quicker, surer solution is to just grab a good JAR from http://www-01.ibm.com/support/docview.wss?uid=swg21363866.