DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30085>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30085 ClassCastException using Oracle BLOB if Oracle JDBC jar is in both /common/lib and [webapp]/lib [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2004-09-17 15:36 ------- First, I don't buy that you have to include the vendor-specific JAR in general to call stored procs: we call stored procs all the time using just the methods and types in the java.sql package. To do otherwise of course ties you to the DB vendor and limits portability. But I can see this being a requirement in a specific case such as yours. To the VM, oracle.sql.BLOB loaded in one classloader is different from oracle.sql.BLOB loaded in another classloader. This is a VM issue, not a Tomcat one. You can read more about in the JLS if you want. Tomcat's ClassLoader model (delegation and all) is dictated by the Servlet Specification. Things loaded in the common classloader cannot see things loaded in the WEB-INF classloaders, it's not our choice as Tomcat implementors, it's mandated by the Spec. Here's one workaround: if you must include the Oracle jar in WEB-INF/lib, put the DBCP (and commons-pool) jars there as well, and configure your own connection pooling instead of using Tomcat's. This is trivial to do and ensures greater portability for your app. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
