GeoTools

Could not obtain native oracle connection

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.7.4
  • Fix Version/s: None
  • Component/s: jdbc-oracle plugin
  • Labels:
    None
  • Environment:
    OS Windows 7 x64, Oracle 11.2.0.2.0, jdk1.6.0_27, apache-tomcat-6.0.35

Description

I'm using GeoTools 2.7.4, a oracle 11g DB, ojdbc14.jar, and a simple java code on a Tomcat 6 like this:

Map map = new HashMap();
map.put( "dbtype", "oracle");
map.put( "jndiReferenceName", "java:comp/env/jdbc/GisDS");

OracleNGJNDIDataStoreFactory factory = new OracleNGJNDIDataStoreFactory();
log.info("Can process? "+ factory.canProcess(map));
store = factory.createDataStore(map);

SimpleFeatureSource featureSource = store.getFeatureSource(viewName);
log.info(featureSource.getFeatures().getBounds().toString());

And my context.xml:

<Resource name="jdbc/GisDS" auth="Container" type="javax.sql.DataSource" 
    driverClassName="oracle.jdbc.driver.OracleDriver"
    accessToUnderlyingConnectionAllowed="true" 
    username="***" password="***"
    url="***"
    maxActive="25" maxIdle="8" maxWait="10000" 
    removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" 
    poolPreparedStatements="true" maxOpenPreparedStatements="100"
    validationQuery="SELECT SYSDATE FROM DUAL"/>

And I always get the "Could not obtain native oracle connection" error:

java.lang.RuntimeException: java.io.IOException: Error occured calculating bounds
        at org.geotools.jdbc.JDBCFeatureSource.getBoundsInternal(JDBCFeatureSource.java:485)
        at org.geotools.jdbc.JDBCFeatureStore.getBoundsInternal(JDBCFeatureStore.java:179)
        at org.geotools.data.store.ContentFeatureSource.getBounds(ContentFeatureSource.java:370)
        at org.geotools.data.store.ContentFeatureCollection.getBounds(ContentFeatureCollection.java:274)
        at ***.GisServlet.doGet(GisServlet.java:82)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Error occured calculating bounds
        at org.geotools.jdbc.JDBCDataStore.getBounds(JDBCDataStore.java:1137)
        at org.geotools.jdbc.JDBCFeatureSource.getBoundsInternal(JDBCFeatureSource.java:478)
        ... 19 more
Caused by: java.sql.SQLException: Could not obtain native oracle connection for class org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper
        at org.geotools.data.oracle.OracleDialect.unwrapConnection(OracleDialect.java:490)
        at org.geotools.data.oracle.OracleDialect.readGeometry(OracleDialect.java:434)
        at org.geotools.data.oracle.OracleDialect.readGeometry(OracleDialect.java:424)
        at org.geotools.data.oracle.OracleDialect.decodeGeometryEnvelope(OracleDialect.java:371)
        at org.geotools.jdbc.JDBCDataStore.getBounds(JDBCDataStore.java:1123)
        ... 20 more

I've tried to connect to a 10g DB, I've tried using the ojdbc6, and I always end with the same result.

The strange is, the featureSource.getFeatures().size() works.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment -
Seems a setup error to me, you did not configure the pool to allow connection unwrapping (we need to access some methods on the actual oracle connection to read geometries)
Show
Andrea Aime added a comment - Seems a setup error to me, you did not configure the pool to allow connection unwrapping (we need to access some methods on the actual oracle connection to read geometries)
Hide
Permalink
Jose Antonio added a comment -
Can you tell me or point me to a place where I can see how to do that? I thought setting the accessToUnderlyingConnectionAllowed property to true and using the OracleNGJNDIDataStoreFactory was enough. I'm battling in this for days and is been really hard to find the documentation to this problem.
Show
Jose Antonio added a comment - Can you tell me or point me to a place where I can see how to do that? I thought setting the accessToUnderlyingConnectionAllowed property to true and using the OracleNGJNDIDataStoreFactory was enough. I'm battling in this for days and is been really hard to find the documentation to this problem.
Hide
Permalink
Andrea Aime added a comment -
Ah, did not see you already added that flag... hum, in that case I have no idea, I normally use Oracle via JNDI using Tomcat 6 and I've never seen that issue... wondering if something changed in recent Tomcat versions that prevents us from unwrapping the connection?
Did you try with slightly older Tomcat versions? I'm positive that with Tomcat 6.0.18 it was working fine.
Show
Andrea Aime added a comment - Ah, did not see you already added that flag... hum, in that case I have no idea, I normally use Oracle via JNDI using Tomcat 6 and I've never seen that issue... wondering if something changed in recent Tomcat versions that prevents us from unwrapping the connection? Did you try with slightly older Tomcat versions? I'm positive that with Tomcat 6.0.18 it was working fine.
Hide
Permalink
Jose Antonio added a comment -
Still no luck. A fresh installation in Tomcat 6.0.18 throws the same error.
In a crazy act I've added all the geoserver libs to my package and it started working, there is something in the main-2.1.3.jar of geoserver that makes the unwrapping possible (if i remove this jar it throws the error). But I can't figure out what it is. Any ideas?
Show
Jose Antonio added a comment - Still no luck. A fresh installation in Tomcat 6.0.18 throws the same error. In a crazy act I've added all the geoserver libs to my package and it started working, there is something in the main-2.1.3.jar of geoserver that makes the unwrapping possible (if i remove this jar it throws the error). But I can't figure out what it is. Any ideas?
Hide
Permalink
Jose Antonio added a comment -
Set up another test in a clean tomcat 6.0.18.
Same results...

if I use

{code}
java.util.Map params = new java.util.HashMap();
params.put( "dbtype", "oracle");
params.put( "host", "***.***.***.***");
params.put( "port", "****");
params.put( "database", "****");
params.put( "user", "****");
params.put( "passwd", "****");
dataStore = DataStoreFinder.getDataStore(params);
SimpleFeatureSource featureSource = dataStore.getFeatureSource("****");
{code}

it works fine, but if I use:

{code}
java.util.Map params = new java.util.HashMap();
params.put( "jndiReferenceName", "java:comp/env/jdbc/GisDS");
dataStore = DataStoreFinder.getDataStore(params);
SimpleFeatureSource featureSource = dataStore.getFeatureSource("****");
{code}

it throws the "Could not obtain native oracle connection" error.
Show
Jose Antonio added a comment - Set up another test in a clean tomcat 6.0.18. Same results... if I use {code} java.util.Map params = new java.util.HashMap(); params.put( "dbtype", "oracle"); params.put( "host", "***.***.***.***"); params.put( "port", "****"); params.put( "database", "****"); params.put( "user", "****"); params.put( "passwd", "****"); dataStore = DataStoreFinder.getDataStore(params); SimpleFeatureSource featureSource = dataStore.getFeatureSource("****"); {code} it works fine, but if I use: {code} java.util.Map params = new java.util.HashMap(); params.put( "jndiReferenceName", "java:comp/env/jdbc/GisDS"); dataStore = DataStoreFinder.getDataStore(params); SimpleFeatureSource featureSource = dataStore.getFeatureSource("****"); {code} it throws the "Could not obtain native oracle connection" error.
Hide
Permalink
Jan De Moerloose added a comment -
I had the same problem with tomcat 6. It turns out tomcat uses its own, package-renamed, version of commons jdbc. I will add a patch here with a tomcat-specific unwrapper that fixes it.
Show
Jan De Moerloose added a comment - I had the same problem with tomcat 6. It turns out tomcat uses its own, package-renamed, version of commons jdbc. I will add a patch here with a tomcat-specific unwrapper that fixes it.
Hide
Permalink
Jan De Moerloose added a comment -
Patch for 2.7.5
Show
Jan De Moerloose added a comment - Patch for 2.7.5
Jan De Moerloose made changes -
Field Original Value New Value
Attachment GEOT-4106.patch [ 61909 ]
Hide
Permalink
Jose Antonio added a comment -
Thank you. I'm no longer working on the project, but I will send your patch to the new person in charge. Thanks again.
Show
Jose Antonio added a comment - Thank you. I'm no longer working on the project, but I will send your patch to the new person in charge. Thanks again.
Hide
Permalink
Andrea Aime added a comment -
Hi Jan, the patch is in the right direction but has two issues:
- it forces another dependency to be downloaded from the maven repo
- it will fail with a class not found exception if the tomcat classes you're referring to are not in the classpath (handling exceptions repeatedly is expensive at runtime)

In GeoServer we use a Spring based unwrapper that does the same job and works with Tomcat too, and the Spring code uses reflection to avoid depending on the classes directly avoiding the two problems above.
The SpringUnWrapper used by GeoServer is here:
http://svn.codehaus.org/geoserver/branches/2.1.x/src/main/src/main/java/org/geoserver/data/jdbc/SpringUnWrapper.java

The code used to unwrap DBCP connections regardless of whether they are from commons or Tomcat is here:
http://www.jarvana.com/jarvana/view/org/springframework/spring/2.5.6.SEC02/spring-2.5.6.SEC02-sources.jar!/org/springframework/jdbc/support/nativejdbc/CommonsDbcpNativeJdbcExtractor.java?format=ok
Show
Andrea Aime added a comment - Hi Jan, the patch is in the right direction but has two issues: - it forces another dependency to be downloaded from the maven repo - it will fail with a class not found exception if the tomcat classes you're referring to are not in the classpath (handling exceptions repeatedly is expensive at runtime) In GeoServer we use a Spring based unwrapper that does the same job and works with Tomcat too, and the Spring code uses reflection to avoid depending on the classes directly avoiding the two problems above. The SpringUnWrapper used by GeoServer is here: http://svn.codehaus.org/geoserver/branches/2.1.x/src/main/src/main/java/org/geoserver/data/jdbc/SpringUnWrapper.java The code used to unwrap DBCP connections regardless of whether they are from commons or Tomcat is here: http://www.jarvana.com/jarvana/view/org/springframework/spring/2.5.6.SEC02/spring-2.5.6.SEC02-sources.jar!/org/springframework/jdbc/support/nativejdbc/CommonsDbcpNativeJdbcExtractor.java?format=ok
Hide
Permalink
Jan De Moerloose added a comment - - edited
Thanks for the pointer, Andrea, i can see the problems with my patch. Am i right that you are suggesting that geotools should not handle this but rather the server code by which it is being used ? If not, can geotools copy the code and/or should we put it in a separate module ?
BTW, i found that jdk1.6 provides the java.sql.Wrapper api for exactly this reason. Is Geotools still stuck to the 1.5 api or would it be an option to use that api in the jdbc dialects ?
Show
Jan De Moerloose added a comment - - edited Thanks for the pointer, Andrea, i can see the problems with my patch. Am i right that you are suggesting that geotools should not handle this but rather the server code by which it is being used ? If not, can geotools copy the code and/or should we put it in a separate module ? BTW, i found that jdk1.6 provides the java.sql.Wrapper api for exactly this reason. Is Geotools still stuck to the 1.5 api or would it be an option to use that api in the jdbc dialects ?
Hide
Permalink
Andrea Aime added a comment -
No, I don't mean the server should be the one doing that, but we cannot have a Spring dependency in GeoTools just for this.
GeoTools 8.x is the first series using Java 6 as its minimum version: maybe you can rework the patch to work on 8.x and thus just use Java 6 API?
Show
Andrea Aime added a comment - No, I don't mean the server should be the one doing that, but we cannot have a Spring dependency in GeoTools just for this. GeoTools 8.x is the first series using Java 6 as its minimum version: maybe you can rework the patch to work on 8.x and thus just use Java 6 API?
Hide
Permalink
Jan De Moerloose added a comment -
I made another patch for the gt-oracle-jdbc component (GEOT-4356). The current geotools Unwrapper API can't delegate to java.sql.Wrapper as it requires you to pass the native connection class. To my disappointment, tomcat dbcp does not implement JDBC4, though, so this fix will not work with tomcat dbcp.
Show
Jan De Moerloose added a comment - I made another patch for the gt-oracle-jdbc component ( GEOT-4356 ). The current geotools Unwrapper API can't delegate to java.sql.Wrapper as it requires you to pass the native connection class. To my disappointment, tomcat dbcp does not implement JDBC4, though, so this fix will not work with tomcat dbcp.

People

  • Assignee:
    Andrea Aime
    Reporter:
    Jose Antonio
Vote (0)
Watch (3)

Dates

  • Created:
    Updated: