Construction of a epsg-oracle CRSAuthority that will work in a Java EE environment
The epsg-oracle plugin is an experiment focused on cleaning up the JDBC Authority abstract classes to ensure the DataSource can be provided.
Actually Using Oracle
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.
The choice of maven profile (to use oracle or to not us oracle) is controlled with a oracle.jdbc system property.
Using Online Tests
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.
You can then run the online tests:
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 (
- They were package-private on purpose. They are usually implementation of public API defined somewhere else. We would need to know why access to those implementation class are wanted, and if there is any way to adress the need without making the implementation class public.
BufferedAuthorityFactoryhad problem with
put(Object, Object)not caching
- Caching should work, at least in 2.4-SNAPSHOT. Need more details about why caching is considered to not work.
AuthorityCodesis only package visisble
- See previous comment about implementation class.
BursaWolfInfois only package visible
- Should NOT be public. This is a very low level implementation detail.
DataSource- this is WRONG we cannot extend
DataSourceon our own (we need to use one provided by others)
- Already deprecated in 2.4-SNAPSHOT for many months. The only reason why it still there is to respect the "deprecate first, delete after next release" cycle.
- Some kind of
DATASOURCE_NAMEto work in JBoss (should be configurable)
- This is already configurable in 2.4-SNAPSHOT through
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
- Not needed anymore, since the local
DataSourceinterface is now deprecated.
createFactory()cannot bind the DataSource into JNDI (will not always have permission)
- 2.4-SNAPSHOT already do not bind anymore.
createBackingStore()needs to close the JDBC connection obtained from the
DataSource(thereby returning it to the pool)
- We already close the connection (since 2.2 I believe), but after a timeout. The default timeout is 20 minutes. We can change that to a lower level, for example 2 minutes.
FactoryUsingAnsiSQL- should not cache the connection (the DataSource will do that)
- We keep the connection until it is closed by the above-cited timeout. We recreate it from the
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
- Again this is a low-level implementation detail that should never be public.
- Some kind of
The following bug reports are important:
- http://jira.codehaus.org/browse/GEOT-909 - EPSG DefaultFactory does not work in an EJB environment
- Need to supply a
DATASOURCE_NAMEhint - should be of the form
"java:EPSG"to keep JBoss happy
- Already done in 2.4-SNAPSHOT.
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.
- The connection is already closed after a timeout (20 minutes by default, but we can change that). It was already working like that in 2.2.
- Need to either use a single factory (may become a bottleneck) or use a pool of factories (will need to fix the
FactoryUsingSQLconnection cache first)
- We need a single instance of
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.
- Need to supply a
- http://jira.codehaus.org/browse/GEOT-908 - FactoryUsingSQL uses Oracle reserved word in query
- http://jira.codehaus.org/browse/GEOT-907 - Caching in BufferedAuthorityFactory does not work
This is a research module, and is not currently tracked using Jira. This is however associated with referencing: