X

Proactive insights, news and tips from Oracle WebLogic Server Support. Learn Oracle from Oracle.

  • September 1, 2015

Using Orachk to Clean Up Concrete Classes for Application Continuity

Stephen Felts
Manager

As I described in
the blog Part
2 - 12c Database and WLS - Application continuity
, Application Continuity (AC) is a great feature
for avoiding errors to the user with minimal changes to the application and
configuration. Getting rid of any
references to Oracle concrete classes is the first step.

Oracle has a utility program that you can download
from MOS to validate various hardware, operating system, and software
attributes associated with the Oracle database and more (it’s growing). The program name is orachk. The latest version is 12.1.0.2.4 and starting
in this version, there are some checks available for applications running with AC.

There is enough documentation about getting started
with orachk so I’ll just say to download and unzip the file. The AC checking is part of a larger framework
that will have additional analysis in future versions. This article focuses on the analysis for
Oracle concrete classes in the application code.

AC is unable
to replay transactions that use oracle.sql deprecated concrete classes of
the form ARRAY, BFILE, BLOB, CLOB,
NCLOB, OPAQUE, REF, or STRUCT as a
variable type, a cast, the return type of a method, or calling a
constructor. See New
Jdbc Interfaces for Oracle types (Doc ID 1364193.1)
for further information
about concrete classes. They must be modified for AC to work with the
application. See Using
API Extensions for Oracle JDBC Types
for many examples of using the newer
Oracle JDBC types in place of the older Oracle concrete types.

There are three values that control the AC checking
(called acchk in orachk) for Oracle concrete classes. They can be set either on the command line or
via shell environment variable (or mixed). They are the following.

Command Line Argument

Shell Environment Variable

Usage

–asmhome jarfilename  

RAT_AC_ASMJAR

This must point to a version of asm-all-5.0.3.jar
that you download from http://asm.ow2.org/.

-javahome JDK8dirname

RAT_JAVA_HOME

This must point to the JAVA_HOME directory for a
JDK8 installation.

-appjar dirname

RAT_AC_JARDIR

To analyze the application code for references to
Oracle concrete classes like oracle.sql.BLOB, this must point to the parent
directory name for the code. The
program will analyze .class files, and recursively .jar files and
directories. If you have J2EE .ear or
.war files, you must recursively explode these into a directory structure
with .class files exposed.

This test works with software classes compiled for
Oracle JDBC 11 or 12.

When you run the AC checking, the additional
checking about database server, etc. is turned off. It would be common to run the concrete class
checking on the mid-tier to analyze software that accesses the Oracle driver.

I chose some old QA test classes that I knew had
some bad usage of concrete classes and ran the test on a small subset for
illustration purposes. The command line
was the following.

$ ./orachk -asmhome /tmp/asm-all-5.0.3.jar -javahome
/tmp/jdk1.8.0_40 -appjar /tmp/appdir

This is a screen shot of the report details. There is additional information reported
about the machine, OS, database, timings, etc.

From this test run, I can see that my one test class
has five references to STRUCT that need to be changed to java.sql.Struct or oracle.jdbc.OracleStruct.

Note that WLS programmers have been using the
weblogic.jdbc.vendor.oracle.* interfaces for over a decade to allow for
wrapping Oracle concrete classes and this AC analysis doesn’t pick that up
(there are five weblogic.jdbc.vendor.oracle.* interfaces that correspond to
concrete classes). These should be
removed as well. For example, trying to
run with this ORACLE extension API and the WLS wrapper

import weblogic.jdbc.vendor.oracle.OracleThinBlob;


rs.next();

OracleThinBlob blob = (OracleThinBlob)rs.getBlob(2);

java.io.OutputStream os = blob.getBinaryOutputStream();

on a Blob column using the normal driver works but
using the replay driver yields

java.lang.ClassCastException:
weblogic.jdbc.wrapper.Blob_oracle_jdbc_proxy_oracle

$1jdbc$1replay$1driver$1TxnReplayableBlob$2oracle$1jdbc$1internal

$1OracleBlob$$$Proxy cannot be cast to
weblogic.jdbc.vendor.oracle.OracleThinBlob

It must be changed to use the standard JDBC API

rs.next();

java.sql.Blob blob = rs.getBlob(2);

java.io.OutputStream os = blob.setBinaryStream(1);

So it’s time to remove references to the deprecated Oracle and
WebLogic classes and preferably migrate to the standard JDBC API’s or at least the new
Oracle interfaces. This will clean up
the code and get it ready to take advantage of Application Continuity in the
Oracle database.

The ORAchk download page is at https://support.oracle.com/epmos/faces/DocumentDisplay?id=1268927.2 .

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha