The epsg-oracle plugin is an experiment focused on cleaning up the JDBC Authority abstract classes to ensure the DataSource can be provided.
To develop this module you will need to follow the optional section in the developers guide for Oracle. This will place an oracle jdbc driver into your local maven repository where it can then be used during the online tests.
C:> cd C:\oracle\product\10.2.0\jdbc\lib C:\oracle\product\10.2.0\jdbc\lib>mvn install:install-file -Dfile=ojdbc14.jar -DgroupId=com.oracle -DartifactId=ojdbc14 -Dversion=10.2.0 -Dpackaging=jar
The choice of maven profile (to use oracle or to not use oracle) is controlled with a oracle property.
mvn clean install -Doracle=true
Or to set up for testing in eclipse:
mvn eclipse:eclipse -Doracle=true
The other thing you will need to do for online tests is place a oracle.properties file describing your database in the magic location below.
user=jody password=*** url=jdbc:oracle:thin:@bilbi:1521:orcl
You can then run the online tests:
mvn -Doracle.jdbc=true test -P online
Some ideas on the use of DataSource in GeoTools (and how we can set up a testing environment are recorded here): J2EE and Connection Pools
In addition the following problems have been noted ...
AbstractAuthorityFactory- some features are just package-visible (
BufferedAuthorityFactoryhad problem with
put(Object, Object)not caching
AuthorityCodesis only package visisble
BursaWolfInfois only package visible
DataSource- this is WRONG we cannot extend
DataSourceon our own (we need to use one provided by others)
DATASOURCE_NAMEto work in JBoss (should be configurable)
DEFAULT_PRIORITY_DECas constructor parameters, either as
DefaultFactory(Hints, int, int)to expose the parent constructor, or as new Hints of their own
createFactory()needs to wrap the
DataSourceobtained from JNDI into a class that implements the local
DataSourceinterface is now deprecated.
createFactory()cannot bind the DataSource into JNDI (will not always have permission)
createBackingStore()needs to close the JDBC connection obtained from the
DataSource(thereby returning it to the pool)
FactoryUsingAnsiSQL- should not cache the connection (the DataSource will do that)
DataSourceafter the timeout. 2.4-SNAPSHOT already do that.
FactoryUsingOracleSQL- addition to
'AS', the Oracle reserved word
'FILE'is replaced in the query Strings. This necessary because one query uses
'FILE'to rename a column in a
SELECTfor a column. This factory is used by the
FactoryUsingSQL- also caches the Connection instead of DataSource
TableInfo- not public
The following bug reports are important:
DATASOURCE_NAMEhint - should be of the form
"java:EPSG"to keep JBoss happy
FactoryUsingSQLshould not remove connection from a pool like
FactoryUsingSQLdoes (need to connect and close on each use). Needed for a multi user environment like Java EE.
FactoryUsingSQLconnection cache first)
BufferedAuthorityFactoryif we want caching to work. It would be possible to update
BufferedAuthorityFactoryin order to handle many instances of
FactoryUsingSQL, but I would like to see if there is really a bottleneck there before to introduce this complication. I was assuming that in typical cases, a user will work with a small set of CRS (~5) appropriate for the area he is working on, in which case many instances of
FactoryUsingSQLwill not give us much.
This is a research module, and is not currently tracked using Jira. This is however associated with referencing: