[Geoserver-devel] Nightly builds failing to deploy, GWC and H2

Andrea_Aime3 · June 7, 2009, 9:22am

Hi,
I've downloaded a nightly build of GeoServer 1.7.x and on deploy I
got this exception:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'gwcMetaStore' defined in URL [jar:file:/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/webapps/geoserver/WEB-INF/lib/gwc-1.7.5-SNAPSHOT.jar!/applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: The H2 database was created by a newer version of the software.
  at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:254)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:835)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
  at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
  at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
  at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
  at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
  at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
  at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
  at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
  at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381)
  at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
  at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
  at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
  at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
  at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
  at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
  at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
  at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
  at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
  at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
  at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
  at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
  at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
  at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
  at org.apache.catalina.core.StandardService.start(StandardService.java:516)
  at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
  at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:585)
  at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
  at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: The H2 database was created by a newer version of the software.
  at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:115)
  at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)
  at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:248)
  ... 41 more
Caused by: org.geowebcache.storage.StorageException: The H2 database was created by a newer version of the software.
  at org.geowebcache.storage.metastore.jdbc.JDBCMBWrapper.checkVariableTable(JDBCMBWrapper.java:173)
  at org.geowebcache.storage.metastore.jdbc.JDBCMBWrapper.checkTables(JDBCMBWrapper.java:116)
  at org.geowebcache.storage.metastore.jdbc.JDBCMBWrapper.<init>(JDBCMBWrapper.java:100)
  at org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend.<init>(JDBCMetaBackend.java:52)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
  at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
  ... 43 more

However I looked around in the data dir and there is no GWC directory... I guess it would be nice to have GWC log where the metastore and other of its configuration files are, just like geoserver logs the data dir location.

For the moment I got unstuck by removing the GWC jar from the GeoServer directory, but it would be nice to get a hold on why this is happening and make sure debugging the issue is easier.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Arne_Kepp · June 8, 2009, 7:02am

Actually it does, probably a few lines earlier. Here's what is printed if it can't find any suitable variables:

WARN [storage.DefaultStorageFinder] - Found no usable default cache prefixes !!! Please set GEOWEBCACHE_CACHE_DIR if you would like a specific location.
WARN [storage.DefaultStorageFinder] - Reverting to java.io.tmpdir: /tmp/geowebcache

Alternatively, starting 1.7.5-bin , which sets GEOSERVER_DATA_DIR as part of the startup scripts:

08 Jun 14:49:45 INFO [storage.DefaultStorageFinder] - Found Servlet context parameter GEOSERVER_DATA_DIR set to /home/ak/temp/geoserver-1.7.5-SNAPSHOT/data_dir, using it as the default prefix.

I think it varies exactly when the message shows up (Spring decides), but it must always happen before such an exception would be thrown.

It's hard to see though, should I aim to make the startup silent ?

-Arne

Andrea Aime wrote:

Hi,
I've downloaded a nightly build of GeoServer 1.7.x and on deploy I
got this exception:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'gwcMetaStore' defined in URL [jar:file:/home/aaime/devel/webcontainers/apache-tomcat-6.0.18/webapps/geoserver/WEB-INF/lib/gwc-1.7.5-SNAPSHOT.jar!/applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: The H2 database was created by a newer version of the software.
  at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:254)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:835)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
  at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
  at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
  at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
  at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
  at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
  at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
  at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
  at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381)
  at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
  at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
  at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
  at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
  at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
  at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
  at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
  at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
  at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
  at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
  at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
  at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
  at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
  at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
  at org.apache.catalina.core.StandardService.start(StandardService.java:516)
  at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
  at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:585)
  at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
  at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: The H2 database was created by a newer version of the software.
  at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:115)
  at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)
  at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:248)
  ... 41 more
Caused by: org.geowebcache.storage.StorageException: The H2 database was created by a newer version of the software.
  at org.geowebcache.storage.metastore.jdbc.JDBCMBWrapper.checkVariableTable(JDBCMBWrapper.java:173)
  at org.geowebcache.storage.metastore.jdbc.JDBCMBWrapper.checkTables(JDBCMBWrapper.java:116)
  at org.geowebcache.storage.metastore.jdbc.JDBCMBWrapper.<init>(JDBCMBWrapper.java:100)
  at org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend.<init>(JDBCMetaBackend.java:52)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
  at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
  ... 43 more

However I looked around in the data dir and there is no GWC directory... I guess it would be nice to have GWC log where the metastore and other of its configuration files are, just like geoserver logs the data dir location.

For the moment I got unstuck by removing the GWC jar from the GeoServer directory, but it would be nice to get a hold on why this is happening and make sure debugging the issue is easier.

Cheers
Andrea

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

Andrea_Aime3 · June 8, 2009, 7:23am

Arne Kepp ha scritto:

Actually it does, probably a few lines earlier. Here's what is printed if it can't find any suitable variables:

WARN [storage.DefaultStorageFinder] - Found no usable default cache prefixes !!! Please set GEOWEBCACHE_CACHE_DIR if you would like a specific location.
WARN [storage.DefaultStorageFinder] - Reverting to java.io.tmpdir: /tmp/geowebcache

Alternatively, starting 1.7.5-bin , which sets GEOSERVER_DATA_DIR as part of the startup scripts:

08 Jun 14:49:45 INFO [storage.DefaultStorageFinder] - Found Servlet context parameter GEOSERVER_DATA_DIR set to /home/ak/temp/geoserver-1.7.5-SNAPSHOT/data_dir, using it as the default prefix.

I think it varies exactly when the message shows up (Spring decides), but it must always happen before such an exception would be thrown.

It's hard to see though, should I aim to make the startup silent ?

On the contrary, I would say that it should be more prominent,
like the message for the GeoServer data directory?
Mind, in my case I just dumped the .war in tomcat, there was
no variable set whatsoever. Don't know what GWC ends up doing in this
case.

I looked again in my logs and indeed the GWC messages were there,
but they are completely anonymous... having GWC somewhere in the
logged category would help finding them:
2009-06-07 10:55:20,478 INFO [util.ApplicationContextProvider] - No context parameter, system or Java environment variables found for GEOSERVER_WMS_URL
2009-06-07 10:55:20,478 INFO [util.ApplicationContextProvider] - Reverting to http://localhost:8080/geoserver/wms?request=GetCapabilities
2009-06-07 10:55:20,478 INFO [util.GetCapabilitiesConfiguration] - Constructing from url http://localhost:8080/geoserver/wms?request=GetCapabilities
2009-06-07 10:55:20,484 WARN [storage.DefaultStorageFinder] - Found no usable default cache prefixes !!! Please set GEOWEBCACHE_CACHE_DIR if you would like a specific location.
2009-06-07 10:55:20,484 WARN [storage.DefaultStorageFinder] - Reverting to java.io.tmpdir: /home/aaime/devel/webcontainers/apache-tomcat-6.0.18/temp/geowebcache
2009-06-07 10:55:23,164 WARN [support.DisposableBeanAdapter] - Couldn't find a destroy method named 'destroy' on bean with name 'gwcDefaultStorageFinder'

So I guess I run a GeoServer 2.0 in the same web container, and
probably on trunk we use a more recent H2 version.
Hmm... until GEoServer 2.0.x is stable I expect people to use
a bit of both, so this issue might become a common occurrence.
Ideas?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime3 · June 8, 2009, 7:29am

Andrea Aime ha scritto:

Arne Kepp ha scritto:

Actually it does, probably a few lines earlier. Here's what is printed if it can't find any suitable variables:

WARN [storage.DefaultStorageFinder] - Found no usable default cache prefixes !!! Please set GEOWEBCACHE_CACHE_DIR if you would like a specific location.
WARN [storage.DefaultStorageFinder] - Reverting to java.io.tmpdir: /tmp/geowebcache

Alternatively, starting 1.7.5-bin , which sets GEOSERVER_DATA_DIR as part of the startup scripts:

08 Jun 14:49:45 INFO [storage.DefaultStorageFinder] - Found Servlet context parameter GEOSERVER_DATA_DIR set to /home/ak/temp/geoserver-1.7.5-SNAPSHOT/data_dir, using it as the default prefix.

I think it varies exactly when the message shows up (Spring decides), but it must always happen before such an exception would be thrown.

It's hard to see though, should I aim to make the startup silent ?

On the contrary, I would say that it should be more prominent,
like the message for the GeoServer data directory?
Mind, in my case I just dumped the .war in tomcat, there was
no variable set whatsoever. Don't know what GWC ends up doing in this
case.

I looked again in my logs and indeed the GWC messages were there,
but they are completely anonymous... having GWC somewhere in the
logged category would help finding them:
2009-06-07 10:55:20,478 INFO [util.ApplicationContextProvider] - No context parameter, system or Java environment variables found for GEOSERVER_WMS_URL
2009-06-07 10:55:20,478 INFO [util.ApplicationContextProvider] - Reverting to http://localhost:8080/geoserver/wms?request=GetCapabilities
2009-06-07 10:55:20,478 INFO [util.GetCapabilitiesConfiguration] - Constructing from url http://localhost:8080/geoserver/wms?request=GetCapabilities
2009-06-07 10:55:20,484 WARN [storage.DefaultStorageFinder] - Found no usable default cache prefixes !!! Please set GEOWEBCACHE_CACHE_DIR if you would like a specific location.
2009-06-07 10:55:20,484 WARN [storage.DefaultStorageFinder] - Reverting to java.io.tmpdir: /home/aaime/devel/webcontainers/apache-tomcat-6.0.18/temp/geowebcache
2009-06-07 10:55:23,164 WARN [support.DisposableBeanAdapter] - Couldn't find a destroy method named 'destroy' on bean with name 'gwcDefaultStorageFinder'

So I guess I run a GeoServer 2.0 in the same web container, and
probably on trunk we use a more recent H2 version.

Oh, in this specific case wouldn't it be possible to have GWC just
follow in the footsteps of GeoServer and use GeoServerDataDirectory
class to locate the data dir?

I guess you could make an extension point, a work area locator,
that you them implement in the geoserver integration module to
just relay to GeoServerDataDirectory.

This would be used when GWC does not find any explicit setting
in the enviroment.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Arne_Kepp · June 8, 2009, 8:08am

Andrea Aime wrote:

Andrea Aime ha scritto:

Arne Kepp ha scritto:

Actually it does, probably a few lines earlier. Here's what is printed if it can't find any suitable variables:

WARN [storage.DefaultStorageFinder] - Found no usable default cache prefixes !!! Please set GEOWEBCACHE_CACHE_DIR if you would like a specific location.
WARN [storage.DefaultStorageFinder] - Reverting to java.io.tmpdir: /tmp/geowebcache

Alternatively, starting 1.7.5-bin , which sets GEOSERVER_DATA_DIR as part of the startup scripts:

08 Jun 14:49:45 INFO [storage.DefaultStorageFinder] - Found Servlet context parameter GEOSERVER_DATA_DIR set to /home/ak/temp/geoserver-1.7.5-SNAPSHOT/data_dir, using it as the default prefix.

I think it varies exactly when the message shows up (Spring decides), but it must always happen before such an exception would be thrown.

It's hard to see though, should I aim to make the startup silent ?

On the contrary, I would say that it should be more prominent,
like the message for the GeoServer data directory?
Mind, in my case I just dumped the .war in tomcat, there was
no variable set whatsoever. Don't know what GWC ends up doing in this
case.

I looked again in my logs and indeed the GWC messages were there,
but they are completely anonymous... having GWC somewhere in the
logged category would help finding them:
2009-06-07 10:55:20,478 INFO [util.ApplicationContextProvider] - No context parameter, system or Java environment variables found for GEOSERVER_WMS_URL
2009-06-07 10:55:20,478 INFO [util.ApplicationContextProvider] - Reverting to http://localhost:8080/geoserver/wms?request=GetCapabilities
2009-06-07 10:55:20,478 INFO [util.GetCapabilitiesConfiguration] - Constructing from url http://localhost:8080/geoserver/wms?request=GetCapabilities
2009-06-07 10:55:20,484 WARN [storage.DefaultStorageFinder] - Found no usable default cache prefixes !!! Please set GEOWEBCACHE_CACHE_DIR if you would like a specific location.
2009-06-07 10:55:20,484 WARN [storage.DefaultStorageFinder] - Reverting to java.io.tmpdir: /home/aaime/devel/webcontainers/apache-tomcat-6.0.18/temp/geowebcache
2009-06-07 10:55:23,164 WARN [support.DisposableBeanAdapter] - Couldn't find a destroy method named 'destroy' on bean with name 'gwcDefaultStorageFinder'

So I guess I run a GeoServer 2.0 in the same web container, and
probably on trunk we use a more recent H2 version.

Oh, in this specific case wouldn't it be possible to have GWC just
follow in the footsteps of GeoServer and use GeoServerDataDirectory
class to locate the data dir?

I guess you could make an extension point, a work area locator,
that you them implement in the geoserver integration module to
just relay to GeoServerDataDirectory.

This would be used when GWC does not find any explicit setting
in the enviroment.

Cheers
Andrea

Ok, done.

In 2.0 that is possible. I was going to do a bit of 2.0 related work today anyway and I will look into that.

-Arne

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers