#222 JDBC parameter getting/setting overhaul

[Stephen Coy]

The getting and setting of JDBC parameters in the CMP2 engine
has been given a bit of an overhaul.

This will have two user visible impacts:

1. CLOBS/BLOBS and large objects in general are now fully
operational with Oracle.
The code used is quite generic and should work against all
databases that support LOBs.
It has been tested against Oracle 9i, Postgres 7.2 and MySQL
3.23.53, (and hsqldb of course).
Don't try to use CLOB mappings with MySQL because:
a) it doesn't have a native CLOB datatype;
b) the jboss code uses ResultSet.getCharacterStream which is
not implemented in the current mysql JDBC driver.

Really large LOBs are probably better handled using BMP,
because the CMP code needs to load the whole thing into
memory.

2. For some reason, previous versions of JBoss mapped java.lang
.Object to a JDBC type of JAVA_OBJECT, and then proceeded to
serialize the object into a binary column.
Some JDBC drivers would accept this behaviour, but many would
not.
JAVA_OBJECT is intended to be mapped to custom types on the
database, and used in conjunction with the java.sql.SQLData/
SQLInput/SQLOutput interfaces, which are managed by the JDBC
driver.
Therefore JAVA_OBJECT types are now passed straight through
to the JDBC driver via set/getObject.
The standard mappings for java.lang.Object that I was able to test
(as in item 1) have been changed to have a binary JDBC type to
preserve the previous behaviour.

NOTE: Anyone who has used JAVA_OBJECT in their jbosscmp-
jdbc.xml will need to change it to VARBINARY,
LONGVARBINARY or BLOB to get the previous behaviour.

IMPORTANT: I have only changed the standard mappings for the
db platforms that I could test. If your database is not mentioned
above I would appreciate feedback on which binary jdbc types are
appropriate.