[geotk] EPSG database and JavaDB/Derby

[Martin Desruisseaux]

Hello Jon

Obviously I'm very pleased if the migration is going well for you :)

To make a short story, there is a simple solution for your concern at the end of 
this email. The rest of this email is only discussion.

Jon Blower a écrit :
> The Geotoolkit referencing bundle includes an EPSG database, which
> requires derby.jar (or some other database engine) to access.  ncWMS
> is a web application so according to the instructions, I shouldn't
> package derby.jar with the WAR file, but install it separately into
> the Tomcat container.  However, this is an extra installation step
> (admittedly a simple one) that is a bit of extra effort for my users.

Yes... But actually we realized that the difficulty goes beyong the case of EPSG 
alone. We are using both Tomcat and Glassfish, and in our experience having JDBC 
driver in WEB-INF/lib is a cause of trouble, no matter which driver (we got the 
same problems with Derby, PostgreSQL and Oracle drivers).

The problem may not be obvious when there is only one application deployed in a 
container (while some symptoms are visible at shutdown time, basically caused by 
the JDBC driver being "shutdown" too early while the web application is also in 
the process of being shutdown. When the JDBC driver is installed in common/lib 
instead, then it is properly "shutdown" only after the web applications). 
However the problem become more serious when there is 2 or more applications 
deployed in the same container. Strange behaviors like NoClassDefFoundError 
(while the JAR is really on the classpath) happen. I think that the problem is 
caused by Tomcat using a different ClassLoader for each web application, causing 
the JVM to consider 2 Derby drivers (or PostgreSQL, etc.) as different classes 
even if they are actually the same, while only one of them can be registered in 
java.sql.Driver or java.util.ServiceLoader (because they have the same class name).

Note that the above apply not only to JDBC drivers, but to anything that 
register itself as a service at the JVM level. In addition to JDBC drivers, this 
apply to ImageReaders & ImageWriters (we are aware that geotk-coverageio declare 
such services, which is an issue that we will need to consider). For this reason 
I would not recommand to put the "Image I/O extension for JAI" JAR file in 
WEB-INF/lib for instance. As a rule of thumbs, for any JAR file for which the 
above command-line display at least one entry:

     unzip -ll thejarfile.jar META-INF/services/java*

putting this JAR file in common/lib instead than WEB-INF/lib is safer. In our 
tests, moving every JDBC drivers in common/lib and making sure that there is 
none remaining in any WEB-INF/lib directory solved a lot of our issues.

For Tomcat users, installing the JDBC drivers in Tomcat is an unconvenient extra 
step. But for the users of a bigger framework like Glassfish, there is no extra 
step because the JDBC drivers are already provided by the container, which also 
manage connection pools etc.


> In GeoTools, I was using the epsg-wkt module, which packaged the CRSs
> in text form without a database engine.  This was very convenient
> because no management of database connections was necessary, and the
> WAR file for ncWMS could be completely self-contained.
> 
> What would be the best way of packaging the CRS database with my web
> application?  I am not very worried about performance.  Is there a WKT
> implementation of the database in Gtk?

Yes. Only the WKT file itself is not provided by Geotk so you need to provide it 
in one of your JAR file. The rational is that the WKT file in GeoTools is 
already a subset of the EPSG database, and different users may want different 
subsets. You can copy the GeoTools property file, eventually add/remove/modify 
some CRS for your area of interest, then put that file in one of your JAR files 
under the following file name:

     org/geotoolkit/referencing/factory/espg/epsg.properties

Thats all. No need to code anything - it should be recognized automatically 
(note however that if a connection to an EPSG database is found, it will have 
precedence over the property file). More information there:

http://www.geotoolkit.org/apidocs/org/geotoolkit/referencing/factory/epsg/PropertyEpsgFactory.html

Please let me know if there is any issue,

	Martin