Re: Tomcat common/lib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ziggy, On 11/14/2009 12:52 PM, Ziggy wrote: Because of this i couldnt really use the connection object provided via JNDI. Sure you can: just use the getInnermostDelegate method to get the real Connection object. You ought to be able to cast that to OracleConnection. It looks like you're already doing that. 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. Right: don't do that. Allow Tomcat to load the Oracle driver from common/lib (because it's necessary if you want to have Tomcat set up your JNDI DataSource) and remove it from your webapp (because it will interfere). Anyway now i only have the driver in common/lib and use just jndi using the underlying connection delegate. Perfect (other than the use of the Oracle-specific stuff). How about java.sql.Array instead? I guess it depends on what you're doing with it... Does this map to an Oracle Type? Presumably, the java.sql.Array type is usable in place of Oracle's oracle.sql.ARRAY type. You just have to figure out how. Since I can't see your code, it's unclear what your code is trying to do. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksAGl4ACgkQ9CaO5/Lv0PC3kQCglpvdmZkPOXLJ+e4tnVAB3E4g uTcAnR3dEdYPNAxPbXoq1r0rIClR0BRn =j/eI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat common/lib
Ziggy These days I'm more familiar with Maven (which solves this simply) however from the days of Ant I think the following might help a little: From memory most ant scripts are custom. You have to add the command to copy libraries etc. You will probably need to add an extra set of commands to the build.xml and a second directory for 'provided' (maven term) libraries. I can't give you much more of a guide than that unless I see the build.xml script. Gerwood -Original Message- From: Ziggy [mailto:zigg...@gmail.com] Sent: Friday, November 13, 2009 7:02 PM To: users@tomcat.apache.org Subject: Tomcat common/lib Hi, When i deploy an application on Tomcat, i have to place the jdbc driver in the $CATALINA_HOME/common/lib folder to be able to use the JNDI facilities. This is fine but when i build the war file using ANT, it refuses to build the war file unless i have the jdbc driver in the application's WEB-INF/lib folder. I dont want to do this because i will then end up with two jar files of the same. i.e. one in Tomcat's common lib and the other in WEB-INF/lib. How can i build the war file without putting the library in WEB-INF/lib? Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat common/lib
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
Re: Tomcat common/lib
Ziggy wrote: When i deploy an application on Tomcat, i have to place the jdbc driver in the $CATALINA_HOME/common/lib folder to be able to use the JNDI facilities. This is fine but when i build the war file using ANT, it refuses to build the war file unless i have the jdbc driver in the application's WEB-INF/lib folder. I dont want to do this because i will then end up with two jar files of the same. i.e. one in Tomcat's common lib and the other in WEB-INF/lib. How can i build the war file without putting the library in WEB-INF/lib? http://tinyurl.com/y8dtu7s Look for definition of path element. You can specify many directories with jar files for use at compile stage. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat common/lib
Excellent thanks. Im only beginning to use ANT so im learning it. Thanks On Fri, Nov 13, 2009 at 8:08 AM, Mikolaj Rydzewski m...@ceti.pl wrote: Ziggy wrote: When i deploy an application on Tomcat, i have to place the jdbc driver in the $CATALINA_HOME/common/lib folder to be able to use the JNDI facilities. This is fine but when i build the war file using ANT, it refuses to build the war file unless i have the jdbc driver in the application's WEB-INF/lib folder. I dont want to do this because i will then end up with two jar files of the same. i.e. one in Tomcat's common lib and the other in WEB-INF/lib. How can i build the war file without putting the library in WEB-INF/lib? http://tinyurl.com/y8dtu7s Look for definition of path element. You can specify many directories with jar files for use at compile stage. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat common/lib
Ziggy wrote: when i build the war file using ANT, it refuses to build the war file unless i have the jdbc driver in the application's WEB-INF/lib folder Do you use any driver specific calls in your code? Since you use JNDI, you should rely only on DataSource provided by container. Hence, no piece of your code should have references to classes from JDBC driver. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat common/lib
No i dont have driver specific code. But something like this raises compilation errors as the jar file that includes the Connection, PreparedStatement and ResultSet objects is not accessible from the WEB-INF/lib folder. Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource) envCtx.lookup(jdbc/EmployeeDB); Connection conn = ds.getConnection(); PreparedStatement lv_pstmt = null; ResultSet lv_rs = null; To be able to compile the above, the jdbc driver in Tomcat/common/lib has to be in the classpath i guess. Thanks On Fri, Nov 13, 2009 at 8:56 AM, Mikolaj Rydzewski m...@ceti.pl wrote: Ziggy wrote: when i build the war file using ANT, it refuses to build the war file unless i have the jdbc driver in the application's WEB-INF/lib folder Do you use any driver specific calls in your code? Since you use JNDI, you should rely only on DataSource provided by container. Hence, no piece of your code should have references to classes from JDBC driver. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat common/lib
Ziggy wrote: No i dont have driver specific code. But something like this raises compilation errors as the jar file that includes the Connection, PreparedStatement and ResultSet objects is not accessible from the WEB-INF/lib folder. Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource) envCtx.lookup(jdbc/EmployeeDB); Connection conn = ds.getConnection(); PreparedStatement lv_pstmt = null; ResultSet lv_rs = null; To be able to compile the above, the jdbc driver in Tomcat/common/lib has to be in the classpath i guess. These are standard J2SE interfaces from java.sql package. There's no need to include any additional jars to compile such code. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat common/lib
Thats interesting.. let me try it again and see the exact compile error that is raised. On Fri, Nov 13, 2009 at 9:18 AM, Mikolaj Rydzewski m...@ceti.pl wrote: Ziggy wrote: No i dont have driver specific code. But something like this raises compilation errors as the jar file that includes the Connection, PreparedStatement and ResultSet objects is not accessible from the WEB-INF/lib folder. Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource) envCtx.lookup(jdbc/EmployeeDB); Connection conn = ds.getConnection(); PreparedStatement lv_pstmt = null; ResultSet lv_rs = null; To be able to compile the above, the jdbc driver in Tomcat/common/lib has to be in the classpath i guess. These are standard J2SE interfaces from java.sql package. There's no need to include any additional jars to compile such code. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat common/lib
Hi,
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
compile:
[echo] Compiling java sources:
[javac] Compiling 146 source files to /u/build/gui2/distribution/classes
[javac] /u/build/ConsignmentDAO.java:84: package
org.apache.tomcat.dbcp.dbcp does not exist
[javac] import org.apache.tomcat.dbcp.dbcp.DelegatingConnection;
[javac] ^
[javac] /u/build/ConsignmentDAO.java:86: cannot find symbol
[javac] symbol : class ARRAY
[javac] location: package oracle.sql
[javac] import oracle.sql.ARRAY;
[javac] ^
[javac] /u/build/gui2/ConsignmentDAO.java:87: cannot find symbol
[javac] symbol : class ArrayDescriptor
[javac] location: package oracle.sql
[javac] import oracle.sql.ArrayDescriptor;
[javac] ^
[javac] /u/build/gui2/SubmitDeclaration.java:43: cannot find symbol
[javac] symbol : class StructDescriptor
[javac] location: package oracle.sql
[javac] import oracle.sql.StructDescriptor;
[javac] ^
[javac] /u/build/lib_ora.java:125: package oracle.jdbc does not exist
[javac] import oracle.jdbc.*;
[javac] ^
[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();
[javac] ^
[javac] /u/build/gui2/ConsignmentDAO.java:383: cannot find symbol
[javac] symbol : class DelegatingConnection
[javac] location: class com.bt.ccs21.data.accessors.ConsignmentDAO
[javac] underlyingConnection =
((DelegatingConnection)underlyingConnection).getDelegate();
[javac] ^
[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);
[javac] /u/build/gui2/data/accessors/ConsignmentDAO.java:396: cannot
find symbol
[javac] symbol : class ARRAY
[javac] location: class data.accessors.ConsignmentDAO
[javac] ARRAY awbNoHwbs = new
ARRAY(rectabDescriptor,underlyingConnection,childLessAwbs);
[javac] ^
[javac] ^
[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]^
[javac] if( !((OracleConnection)
mainConnection).getImplicitCachingEnabled())
[javac]^
[javac] ((OraclePreparedStatement)pStatement).close();
[javac] ^
[javac] ((OracleConnection)
mainConnection).setStatementCacheSize( gJDBC_StatementCacheSize );
[javac] ^
[javac] +
((OracleConnection) mainConnection).getStatementCacheSize() );
[javac] ^
[javac]
^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
On Fri, Nov 13, 2009 at 12:28 PM, Ziggy zigg...@gmail.com wrote:
Thats interesting.. let me try it again and see the exact compile error
that is raised.
On Fri, Nov 13, 2009 at 9:18 AM, Mikolaj Rydzewski m...@ceti.pl wrote:
Ziggy wrote:
No i dont have driver specific code. But something like this raises
compilation errors as the jar file that includes the Connection,
PreparedStatement and ResultSet objects is not accessible from the
WEB-INF/lib folder.
Context envCtx = (Context) initCtx.lookup(java:comp/env);
DataSource ds = (DataSource)
envCtx.lookup(jdbc/EmployeeDB);
Connection conn = ds.getConnection();
Re: Tomcat common/lib
-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
