The problem i had with the Oracle specific functions is that they only work
if the connection object is of a oracle.jdbc.driver.OracleConnection type.
I am using Oracle Specific Types which i found are just a pain to use with
Java because they cause lots of issues one of them being interfacing with
Java programs.
This is an issue because when i get the connection object from a DataSource
object that I lookup via JNDI, the connection is not a real OracleConnection
object, but an object that wraps the real OracleConnection. The object that
you get is an instance of class org.apache.commons.dbcp.BasicDataSource.
When you call getConnection on this object, you get an instance of class
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper (which
obviously implements java.sql.Connection, and wraps the OracleConnection
object).
Because of this i couldnt really use the connection object provided via
JNDI. I did initially just bypass jndi and created a new conneciton via
java.sql.Connection. This worked fine for a couple of months but then i
decided to change it as it became a pain to have to maintain the database
properties in two places. I.e. on the jndi properties and the properties
file for the direct connection.
The other problem i had is that when i had two connection types, i was
getting lots of problems with the way the driver was being loaded. I think
this was because Tomcat was already loading the jdbc driver via common/lib
and i had the driver in WEB-INF/lib it was not happy about it. Anyway now i
only have the driver in common/lib and use just jndi using the underlying
connection delegate.
I had a look around and found that i could get the underlying connection
from the
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper object
which is what i did. Now i dont have to maintain the database properties in
two places.
>How about java.sql.Array instead? I guess it depends on what you're
>doing with it...
Does this map to an Oracle Type?
I will play around with it to try some of your suggestions and see what
happens. Thanks for the help.
Thanks
On Fri, Nov 13, 2009 at 2:22 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ziggy,
>
> On 11/13/2009 8:15 AM, Ziggy wrote:
> > yes i think you are right. The compiler errors are not on the Connection,
> > PreparedStatement objects references but rather on some specific
> references.
> > Here are a couple of examples
>
> Yes, you are using implementation-specific classes:
>
> > [javac] /u/build/ConsignmentDAO.java:84: package
> > org.apache.tomcat.dbcp.dbcp does not exist
> > [javac] import org.apache.tomcat.dbcp.dbcp.DelegatingConnection;
>
> Do you need to reference the oat.DelegatingConnection, or would
> java.sql.Connection work just fine?
>
> > [javac] /u/build/ConsignmentDAO.java:86: cannot find symbol
> > [javac] symbol : class ARRAY
> > [javac] location: package oracle.sql
> > [javac] import oracle.sql.ARRAY;
>
> How about java.sql.Array instead? I guess it depends on what you're
> doing with it...
>
> > [javac] /u/build/gui2/ConsignmentDAO.java:381: cannot find symbol
> > [javac] symbol : class DelegatingConnection
> > [javac] location: class com.bt.ccs21.data.accessors.ConsignmentDAO
> > [javac] if (conn instanceof
> > DelegatingConnection){
> > [javac] ^
> > [javac] /u/build/gui2/ConsignmentDAO.java:382: cannot find symbol
> > [javac] symbol : class DelegatingConnection
> > [javac] location: class com.bt.ccs21.data.accessors.ConsignmentDAO
> > [javac] underlyingConnection =
> > ((DelegatingConnection)conn).getDelegate();
>
> Aah, if you need to get the underlying connection, then you'll need to
> cast to Tomcat's implementation. Note that you can use reflection to
> avoid static typecasting and maybe free yourself from needing to have
> the Tomcat classes around for compilation.
>
> Why do you need to access the underlying connection? Probably do to some
> Oracle-specific stuff:
>
> > [javac] /u/build/gui2/ConsignmentDAO.java:395: cannot find symbol
> > [javac] symbol : class ArrayDescriptor
> > [javac] location: class data.accessors.ConsignmentDAO
> > [javac] ArrayDescriptor rectabDescriptor
> =
> > ArrayDescriptor.createDescriptor("LIST_TYPE",underlyingConnection);
>
> I believe you can use native Java arrays for some if this stuff, as long
> as you have properly configured your driver. You may have to toy with
> the type mapper on the Connection object, though.
>
> I know that dealing with SQL ARRAY types is usually pretty hacky. Have
> you tried simple things like just doing:
>
> int[] ints = ...;
> callableStatement.setObject(n, ints);
>
> ... and see what happens?
>
> > [javac] /u/build/common/java/com/rms_lib_ora.java:350: cannot find
> > symbol
> > [javac] symbol : class OracleConnection
> > [javac] location: class com.bt.ccs21.common_java.rms_lib_ora
> > [javac] if( !((OracleConnection)
> > mainConnection).getImplicitCachingEnabled())
>
> ???!
>
> > [javac] if( !((OracleConnection)
> > mainConnection).getImplicitCachingEnabled())
> > [javac] ^
> >
> > [javac]
> ((OraclePreparedStatement)pStatement).close();
> > [javac] ^
> >
> > [javac] ((OracleConnection)
> > mainConnection).setStatementCacheSize( gJDBC_StatementCacheSize );
>
> You ought to set this type of thing in the driver's connection string.
>
> Note that, whatever libraries are required for compilation, you can
> always exclude them from the WAR file when you build it. Look for the
> <excludes> element in the Ant manual. You can simply tell ant to avoid
> particular libraries when building the WAR.
>
> We actually have a top-level lib directory for each of our projects, and
> then subdirectories within it to hold various libraries. Anything
> required to run the webapp goes directly in lib; anything required to
> build it (not not necessarily run it) goes in lib/build; anything
> required to test the webapp goes into lib/test. When we build the WAR
> file, we only include lib/*.jar (and ignore anything in subdirectories).
>
> Perhaps a strategy like this will help you, here.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkr9a6kACgkQ9CaO5/Lv0PC8ngCgmLbhFERY/m3PcsX+WhfyrdWX
> RRoAn3XJBYFslOzs5XasKdYs2ZjXsGCn
> =mGd5
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
