H2 version in GeoScript

[scottie]

Hello Justin,

I have a question for you regarding the H2 workspace as

I think you are the gt-jdbc-h2 maintainer.

Currently,   1.1.x  is the dependency,   1.3.x is out.   

I don't think the database formats are compatible,  are

they?    And,  would what be the ramification is the 

newer version was swapped in?

Just curious.

Thanks!

--scottie

[Justin Deoliveira]

Hey Scottie,

Yeah, the h2 dependency hasn't been updated in a while. I am actually not sure if the formats are compatible or not. I guess it would be nice to know for sure before deciding on an upgrade. If 1.3.x is at least backward compatible with 1.1.x then it wouldn't be too much of a deal to upgrade. 

Any chance you want to try swapping in the new version to see how it goes?

-Justin

--
--
You received this message because you are subscribed to the GeoScript mailing list.
To post to this group, send email to geos...@googlegroups.com
To unsubscribe from this group, send email to geoscript+...@googlegroups.com
Visit this group at http://groups.google.com/group/geoscript or see http://geoscript.org
 
---
You received this message because you are subscribed to the Google Groups "GeoScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geoscript+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Justin Deoliveira

OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

[Andrea Aime]

On Thu, Apr 25, 2013 at 5:05 PM, Justin Deoliveira <jdeo...@opengeo.org> wrote:

Hey Scottie,

Yeah, the h2 dependency hasn't been updated in a while. I am actually not sure if the formats are compatible or not. I guess it would be nice to know for sure before deciding on an upgrade. If 1.3.x is at least backward compatible with 1.1.x then it wouldn't be too much of a deal to upgrade. 

Any chance you want to try swapping in the new version to see how it goes?

See the current thread on the geoserver-users mailing list, past 1.2.something H2 is no longer able to read the

1.1 format

Cheers

Andrea

 

--

==

GeoServer training in Milan, 6th & 7th June 2013!  Visit http://geoserver.geo-solutions.it for more information.
==

Ing. Andrea Aime 

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054  Massarosa (LU)

Italy

phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39  339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

-------------------------------------------------------

[scott bortman]

Justin,

Regarding swapping out the H2 jar:    Bzzzzzzzt.   No likey.

All appears to go well until the workspace is closed.  Here's the 

strack trace, if it helps:

Caught: java.lang.AbstractMethodError: net.sourceforge.hatbox.jts.DeleteTrigger.close()V

java.lang.AbstractMethodError: net.sourceforge.hatbox.jts.DeleteTrigger.close()V

at org.h2.schema.TriggerObject.close(TriggerObject.java:372)

at org.h2.engine.Database.close(Database.java:1133)

at org.h2.engine.Database.removeSession(Database.java:1027)

at org.h2.engine.Session.close(Session.java:563)

at org.h2.jdbc.JdbcConnection.close(JdbcConnection.java:365)

at org.apache.commons.dbcp.DelegatingConnection.close(DelegatingConnection.java:247)

at org.apache.commons.dbcp.PoolableConnection.reallyClose(PoolableConnection.java:122)

at org.apache.commons.dbcp.PoolableConnectionFactory.destroyObject(PoolableConnectionFactory.java:628)

at org.apache.commons.pool.impl.GenericObjectPool.destroy(GenericObjectPool.java:1291)

at org.apache.commons.pool.impl.GenericObjectPool.clear(GenericObjectPool.java:1279)

at org.apache.commons.pool.impl.GenericObjectPool.close(GenericObjectPool.java:1438)

at org.apache.commons.dbcp.BasicDataSource.close(BasicDataSource.java:1314)

at org.geotools.data.jdbc.datasource.DBCPDataSource.close(DBCPDataSource.java:47)

at org.geotools.jdbc.JDBCDataStore.dispose(JDBCDataStore.java:4314)

at org.geotools.data.DataAccess$dispose.call(Unknown Source)

at geoscript.workspace.Workspace.close(Workspace.groovy:192)

at geoscript.workspace.Workspace$close.call(Unknown Source)

at Stager.stageDirectory(pedStager.groovy:125)

at Stager$stageDirectory.call(Unknown Source)

at pedStager.run(pedStager.groovy:144)

Thanks,

--scottie

--

[Justin Deoliveira]

Thanks guys.

Scottie, can you open a ticket in the geotools tracker for this? I'll take a look at see if we can make the datastore work with both versions.

-Justin

[scott bortman]

I can try,  never done that before.   Hopefully a dummy like me 

can figure that out. ;-)

[scott bortman]

Figured it out,   Added my wish to gt-jdbc-h2 JIRA.

Thanks!

--scottie

[scottie]

Greetings,

I had a little time to investigate this further and think I've

found the solution.   GeoDB depends on an older version

of HatBox.   Upgrading to the latest Hatbox will let you

use H2 1.3.x.    I put the following my pom.xml file for

GeoScript:

        <dependency>

            <groupId>org.opengeo</groupId>

            <artifactId>geodb</artifactId>

            <version>0.7</version>

        </dependency>

        <dependency>

            <groupId>com.h2database</groupId>

            <artifactId>h2</artifactId>

            <version>1.3.172</version>

        </dependency>

        <dependency>

            <groupId>net.sourceforge.hatbox</groupId>

            <artifactId>hatbox</artifactId>

            <version>1.0.b9</version>

        </dependency>

It works but there is a CAVEAT.   HatBox jar file is packaged w/some

code that is in the java.sql package.   I assume that stuff is there only

for building purposes and not meant to be package in final jar.   Removing

those classes from the jar makes it all work rather nicely (in my limited testing).   

So,  Jared,  Justin,   either one of you know who puts the hatbox jars on the 

opengeo repo?   Any chance we can get them to not package the java.sql stuff?

Hope this helps,

-scottie 

[Justin Deoliveira]

Hey Scottie,

It would have been me that posted the hatbox jar in the opengeo repo. It looks like the hatbox author added the stub classes to maintain source compatibility with both java 5 and 6.

I guess i am kind of hesitant to remove the classes from the existing jar since it would break java 5 runtimes.

I guess we could always throw a new jar in there with a classifier (hatbox-1.0b9-jdk16) that removes the java 1.6 compatibility classes, and remove those classes. Maybe that is the safest way forward. 

I'll post the jar shortly and then perhaps you can test it out for me scottie? 

-Justin

--

--
You received this message because you are subscribed to the GeoScript mailing list.
To post to this group, send email to geos...@googlegroups.com
To unsubscribe from this group, send email to geoscript+...@googlegroups.com
Visit this group at http://groups.google.com/group/geoscript or see http://geoscript.org
 
---
You received this message because you are subscribed to the Google Groups "GeoScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geoscript+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[scott bortman]

Ah,   okay,  that makes sense regarding the inclusion of those interfaces.    Though maybe

a better solution would be to put them in a separate jar?   Not sure what's best. 

But,   I'd be happy to try out your new jar.   I'll keep an eye out for it and let ya know.

Thanks again for looking into it.

And,  Happy 4th of July to you!

--scottie

[Justin Deoliveira]

Great. The jar is up.

http://repo.opengeo.org/net/sourceforge/hatbox/hatbox/1.0.b9/hatbox-1.0.b9-jdk16.jar

Happy 4th as well! Don't work too hard :)

[scott bortman]

Justin,

The jar is good!   Thanks for the speedy turnaround.    Question:   

Should it be in: 

/net/sourceforge/hatbox/hatbox/1.0.b9-jdk16 

rather than:

/net/sourceforge/hatbox/hatbox/1.0.b9

or

Or do I have this wrong:

        <dependency>

            <groupId>net.sourceforge.hatbox</groupId>

            <artifactId>hatbox</artifactId>

            <version>1.0.b9-jdk16</version>

        </dependency>

I installed the jar into my local repo,  ran my test,  and it worked.

Thanks again,

--scottie

[Justin Deoliveira]

No problem.

Actually it's a classifier, so I think the dependency looks like this.

       <dependency>

            <groupId>net.sourceforge.hatbox</groupId>

            <artifactId>hatbox</artifactId>

            <version>1.0.b9</version>

            <classifier>jdk16</classifier>

        </dependency>

Let me know if that works.

[scott bortman]

Well,   when I do that  I get both jars.    Oh well,   I can just remove the old one.

Thanks for helping!

--scottie

PS:   You taught me something new w/maven,   I guess I better read up more on  it.

[Justin Deoliveira]

On Thu, Jul 4, 2013 at 1:26 PM, scott bortman <scott....@gmail.com> wrote:

Well,   when I do that  I get both jars.    Oh well,   I can just remove the old one.

Thanks for helping!

Hmmm... that was not intended. I'll look into it. 

--scottie

PS:   You taught me something new w/maven,   I guess I better read up more on  it.

Yeah, classifiers are a bit of an obscure feature, mostly only used for isolating test artifacts but I have seen them used in this manner as well.