Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Right now GeoTools makes use of JDBC Connections in the following scenarios:

  • EPSG Authority implementations (for Postgres, HSQL, Access and soon Oracle)
  • DataStore implementations (for PostGIS, Oracle, HSQL, H2, MySQL, etc...)

We need to ensure that GeoTools can be used safely in a J2EE environment; specifically we need to allow GeoTools based applications to configure the library with an externally defined DataSource (usually manged by a J2EE container provided connection pool).


How to "unwrap" changes based on the implementation returned by DataSource.getConnection():

  • Direct: cast returned Connection to (OracleConnection)
  • DBCP: cast to specific DBCPPooledConnection and ask for the wrapped connection
  • C3PO: use reflection to access a private field
  • etc...

Because this is an open ended set .. and we do not have access to all implementations (say OC4L) we are going to have to make an extension point to handle this case.


This problem has been reported (and fixed) for the case of Oracle in a JBoss environment:

The solution was not general (a dependency on JBoss was introduced in the attached Java code). Good to know we are on the right track.


The base class (EPSGDefaultFactory) is already set up to use DataSource, we had some initial trouble where it would try to register a DataSource if one was not already provided (this has since been repressed).

The code currently uses JNDI to look for a DataSource registered at "java:EPSG". There are a couple of problems here ...

  • Each subclass targets a DataSource in the same location
    • Actual location of DataSource to a EPSG database may change from application to application (or site to site)
  • Database independence
    • It looks like we need to synchronize the DataSource and EPSGDefaultFactory used? It would be nice to have JNDI be the only thing an application needs to get right (so they can switch between Postgres and Oracle without having to redeploy all GeoTools based applications with different jars)
    • Write the EPSGDefaultFactory support in such a way that it is database independent. That is use strategy objects for implementation specific SQL needs, rather then subclassing.

Rough Plan:

  1. Add DBCP connection pool implementation to our build (and use it as the "default" rather then DirectConnection)
  2. Test that EPSGDefaultFactory works with DataSource
  3. Produce a second Factory that accepts an arbitraty JNDI datasource, it will be up to client applications to configure this Factory and add it into the GeoTools mix (using Hints?)