[geotk] EPSG database and JavaDB/Derby

[Jon Blower]

Hi Martin,

Thanks for the very helpful information.  I grabbed the
epsg.properties file from a GeoTools distribution, and put it in my
source tree under org/geotoolkit/referencing/factory/espg.  I still
get jdbc/derby connection errors when trying to instantiate EPSG:4326.
 I've checked that the epsg.properties file ends up correctly in the
WEB-INF/classes folder.  I haven't put the properties file in a
separate jar but I don't think this should matter.

Am I doing something wrong?

Jon

On Wed, Oct 7, 2009 at 12:12 AM, Martin Desruisseaux
<martin.desruisseaux at geomatys.fr> wrote:
> 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
>



-- 
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower at reading.ac.uk
http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm