[geotk] EPSG database and JavaDB/Derby
martin.desruisseaux at geomatys.fr
Tue Oct 6 19:12:03 EDT 2009
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:
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:
Please let me know if there is any issue,
More information about the Geotoolkit