Hi,
today I've opened a data dir with 2.0.x, then with GS trunk,
and after some minutes again with 2.0.x and I was greeted by
a stack trace (see the end of the mail).
Is the persistence on trunk/2.1.x become backwards incompatible
with 2.0.x? If that is actually so, any idea of how to manually
modify the data dir contents to get back a working 2.0.x data directory?
Cheers
Andrea
-----------------------------------------------------------------
02 feb 14:52:52 ERROR [mortbay.log] - Failed startup of context org.mortbay.jetty.webapp.WebAppContext@anonymised.com{/geoserver,src/main/webapp}
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'geoServer' defined in URL [file:/home/aaime/devel/gs2.0.x/src/main/target/classes/applicationContext.xml]: Initialization of bean failed; nested exception is java.lang.RuntimeException: com.thoughtworks.xstream.converters.ConversionException: globalServices : globalServices : globalServices : globalServices
---- Debugging information ----
message : globalServices : globalServices
cause-exception : com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message : globalServices : globalServices
class : org.geoserver.config.impl.GeoServerInfoImpl
required-type : org.geoserver.config.impl.GeoServerInfoImpl
line number : 22
-------------------------------
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480)
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.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:540)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.geoserver.web.Start.main(Start.java:66)
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I would say it has become forward incompatible yes 
And yes this is somewhat of a pain with xstream. It would be nice if we had a way to tell it to ignore this case, aka not fail when there is a field in some output that has no corresponding field in a class.
If you want to modify the data directory directly simply remove the globalServices element in global.xml.
We could also just add a "dummy" globalServices field to GeoServerInfo on 2.0.x. It would never get used or called but would us to be forward compatible.
-Justin
On 2/2/10 8:56 AM, Andrea Aime wrote:
Hi,
today I've opened a data dir with 2.0.x, then with GS trunk,
and after some minutes again with 2.0.x and I was greeted by
a stack trace (see the end of the mail).
Is the persistence on trunk/2.1.x become backwards incompatible
with 2.0.x? If that is actually so, any idea of how to manually
modify the data dir contents to get back a working 2.0.x data directory?
Cheers
Andrea
-----------------------------------------------------------------
02 feb 14:52:52 ERROR [mortbay.log] - Failed startup of context
org.mortbay.jetty.webapp.WebAppContext@anonymised.com{/geoserver,src/main/webapp}
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'geoServer' defined in URL
[file:/home/aaime/devel/gs2.0.x/src/main/target/classes/applicationContext.xml]:
Initialization of bean failed; nested exception is
java.lang.RuntimeException:
com.thoughtworks.xstream.converters.ConversionException: globalServices
: globalServices : globalServices : globalServices
---- Debugging information ----
message : globalServices : globalServices
cause-exception :
com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message : globalServices : globalServices
class : org.geoserver.config.impl.GeoServerInfoImpl
required-type : org.geoserver.config.impl.GeoServerInfoImpl
line number : 22
-------------------------------
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480)
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.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:540)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.geoserver.web.Start.main(Start.java:66)
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
I would say it has become forward incompatible yes
And yes this is somewhat of a pain with xstream. It would be nice if we had a way to tell it to ignore this case, aka not fail when there is a field in some output that has no corresponding field in a class.
This page has a mention of that:
http://xstream.codehaus.org/faq.html#Serialization_newer_class_versions
It seems there is a test that implement that kind of unknown field
skipping.
I'm sure I've seen an announcement of a library for xml configuration
persistence that actually handled explicitly such problems, I think
it was implemented by a German company, but for the life of me I
cannot find the site anymore... Oh well, was just an interesting link
anyways.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
I'm sure I've seen an announcement of a library for xml configuration
persistence that actually handled explicitly such problems, I think
it was implemented by a German company, but for the life of me I
cannot find the site anymore... Oh well, was just an interesting link
anyways.
Oh, found it. It's an interesting read:
http://serialization.cedarsoft.org/
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 2/2/10 10:00 AM, Andrea Aime wrote:
Andrea Aime ha scritto:
I'm sure I've seen an announcement of a library for xml configuration
persistence that actually handled explicitly such problems, I think
it was implemented by a German company, but for the life of me I
cannot find the site anymore... Oh well, was just an interesting link
anyways.
Oh, found it. It's an interesting read:
http://serialization.cedarsoft.org/
Interesting indeed. Too bad it was not around when we chose xstream Seriously though the first class support for versioning seems exactly what we need. Oh well... maybe for GeoServer 3.0 
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Andrea Aime ha scritto:
Justin Deoliveira ha scritto:
I would say it has become forward incompatible yes
And yes this is somewhat of a pain with xstream. It would be nice if we had a way to tell it to ignore this case, aka not fail when there is a field in some output that has no corresponding field in a class.
This page has a mention of that:
http://xstream.codehaus.org/faq.html#Serialization_newer_class_versions
It seems there is a test that implement that kind of unknown field
skipping.
And here we go with a patch based on that XStream test:
http://jira.codehaus.org/browse/GEOS-3797
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.