[Geoserver-devel] GeoServer fails with Spring 2.5

Hello!

We are using GeoServer as a part of web application (several GeoServer's
modules: data, platform, main, ows,..). It serves as an engine to
load/persist features directly from/to their datastores and lets us to reuse
rich configuration of datastores and feature types in XML, gives direct
access to features without WFS XML request/response expenses and so on. But
the web application relies on the Spring 2.5 which is more strict then
1.2.x.

Basic configuration of GeoServer beans looks like:

======================================================
  <!-- GeoServer configuration -->

  <!-- resources -->
  <bean id="resourceLoader"
class="org.geoserver.platform.GeoServerResourceLoader" />

  <!-- configuration module -->
  <bean id="config" class="org.vfny.geoserver.global.Config" />

  <!-- geoserver module -->
  <bean id="geoServer" class="org.vfny.geoserver.global.GeoServer">
    <constructor-arg ref="config" />
  </bean>
  <bean id="globalConfig"
class="org.vfny.geoserver.config.GlobalConfig">
    <constructor-arg ref="geoServer" />
  </bean>

  <!-- data module -->
  <bean id="data" class="org.vfny.geoserver.global.Data">
    <constructor-arg ref="config" />
    <constructor-arg ref="geoServer" />
  </bean>
  <alias name="data" alias="catalog" />

  <bean id="dataConfig" class="org.vfny.geoserver.config.DataConfig">
    <constructor-arg ref="data" />
  </bean>

=================================================

WebApplictionContext.refresh() method fails during starting of the Spring
container because it calls ApplicationContext.destroy() methods of classes
that implement DisplosableBean interface like
org,vfny.geoserver.global.GeoServer class. destroy() method of the last one
tries to get a bean during destroying Spring container during refreshing
process, it causes an exception with Spring 2.5:

============================================================

19:34:16 ERROR [support.DisposableBeanAdapter] - Couldn't invoke destroy
method of bean with name 'geoServer'
org.springframework.beans.factory.BeanCreationNotAllowedException: Error
creating bean with name 'data': Singleton bean creation not allowed while
the singletons of this factory are in destruction (Do not request a bean
from a BeanFactory in a destroy method implementation!)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi
ngleton(DefaultSingletonBeanRegistry.java:156)
  at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:248)
  at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:170)
  at
org.springframework.context.support.AbstractApplicationContext.getBean(Abstr
actApplicationContext.java:883)
  at org.vfny.geoserver.global.GeoServer.destroy(GeoServer.java:1033)
  at
org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(Disp
osableBeanAdapter.java:154)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oyBean(DefaultSingletonBeanRegistry.java:397)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oySingleton(DefaultSingletonBeanRegistry.java:375)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oySingletons(DefaultSingletonBeanRegistry.java:348)
  at
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr
actApplicationContext.java:377)

=====================================================================

The idea is to make GeoServer bean aware about Data by a local reference to
its instance or implement DisposableBean interface in Data class itself and
move functionality from GeoServer.destroy() to Data.destroy().

I have just started to test GeoServer 1.6.x with Spring 2.5 in the context
of our webapp architecture, may be there are other places that would be
desirable to make compatible with Spring 1.2.x and Spring 2.5.

Vitali Diatchkov.

Hi Vitali,

I too tried this before and ran into similar issues, but did not spend too much time looking into this.

I am creating a jira issue for this:

http://jira.codehaus.org/browse/GEOS-1831

Sooner or later we will officially move to Spring 2. When will be a community decision, but ironing out the issues before hand will not hurt.

-Justin

Vitali Diatchkov wrote:

Hello!

We are using GeoServer as a part of web application (several GeoServer's
modules: data, platform, main, ows,..). It serves as an engine to
load/persist features directly from/to their datastores and lets us to reuse
rich configuration of datastores and feature types in XML, gives direct
access to features without WFS XML request/response expenses and so on. But
the web application relies on the Spring 2.5 which is more strict then
1.2.x.

Basic configuration of GeoServer beans looks like:

======================================================
  <!-- GeoServer configuration -->

  <!-- resources -->
  <bean id="resourceLoader"
class="org.geoserver.platform.GeoServerResourceLoader" />

  <!-- configuration module -->
  <bean id="config" class="org.vfny.geoserver.global.Config" />

  <!-- geoserver module -->
  <bean id="geoServer" class="org.vfny.geoserver.global.GeoServer">
    <constructor-arg ref="config" />
  </bean>
  <bean id="globalConfig"
class="org.vfny.geoserver.config.GlobalConfig">
    <constructor-arg ref="geoServer" />
  </bean>

  <!-- data module -->
  <bean id="data" class="org.vfny.geoserver.global.Data">
    <constructor-arg ref="config" />
    <constructor-arg ref="geoServer" />
  </bean>
  <alias name="data" alias="catalog" />

  <bean id="dataConfig" class="org.vfny.geoserver.config.DataConfig">
    <constructor-arg ref="data" />
  </bean>

=================================================

WebApplictionContext.refresh() method fails during starting of the Spring
container because it calls ApplicationContext.destroy() methods of classes
that implement DisplosableBean interface like
org,vfny.geoserver.global.GeoServer class. destroy() method of the last one
tries to get a bean during destroying Spring container during refreshing
process, it causes an exception with Spring 2.5:

============================================================

19:34:16 ERROR [support.DisposableBeanAdapter] - Couldn't invoke destroy
method of bean with name 'geoServer'
org.springframework.beans.factory.BeanCreationNotAllowedException: Error
creating bean with name 'data': Singleton bean creation not allowed while
the singletons of this factory are in destruction (Do not request a bean
from a BeanFactory in a destroy method implementation!)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi
ngleton(DefaultSingletonBeanRegistry.java:156)
  at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:248)
  at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:170)
  at
org.springframework.context.support.AbstractApplicationContext.getBean(Abstr
actApplicationContext.java:883)
  at org.vfny.geoserver.global.GeoServer.destroy(GeoServer.java:1033)
  at
org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(Disp
osableBeanAdapter.java:154)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oyBean(DefaultSingletonBeanRegistry.java:397)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oySingleton(DefaultSingletonBeanRegistry.java:375)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oySingletons(DefaultSingletonBeanRegistry.java:348)
  at
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr
actApplicationContext.java:377)

=====================================================================

The idea is to make GeoServer bean aware about Data by a local reference to
its instance or implement DisposableBean interface in Data class itself and
move functionality from GeoServer.destroy() to Data.destroy().

I have just started to test GeoServer 1.6.x with Spring 2.5 in the context
of our webapp architecture, may be there are other places that would be
desirable to make compatible with Spring 1.2.x and Spring 2.5.

Vitali Diatchkov.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47ea91d3228191637810514!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

What are our reasons for not upgrading GeoServer to Spring 2.5? It seems like 1.2 is not all that supported any more, and that being on 2.5 might give us better compatibility with other projects? Plus if we have bugs they are more likely to get fixed - if we have a bug with 1.2 it'd be like people asking us to fix a bug in GS 1.3...

It seems like now would be a good time to do the upgrade on trunk, while it's still in beta.

Chris

Justin Deoliveira wrote:

Hi Vitali,

I too tried this before and ran into similar issues, but did not spend too much time looking into this.

I am creating a jira issue for this:

http://jira.codehaus.org/browse/GEOS-1831

Sooner or later we will officially move to Spring 2. When will be a community decision, but ironing out the issues before hand will not hurt.

-Justin

Vitali Diatchkov wrote:

Hello!

We are using GeoServer as a part of web application (several GeoServer's
modules: data, platform, main, ows,..). It serves as an engine to
load/persist features directly from/to their datastores and lets us to reuse
rich configuration of datastores and feature types in XML, gives direct
access to features without WFS XML request/response expenses and so on. But
the web application relies on the Spring 2.5 which is more strict then
1.2.x.

Basic configuration of GeoServer beans looks like:

======================================================
  <!-- GeoServer configuration -->

  <!-- resources -->
  <bean id="resourceLoader"
class="org.geoserver.platform.GeoServerResourceLoader" />

  <!-- configuration module -->
  <bean id="config" class="org.vfny.geoserver.global.Config" />

  <!-- geoserver module -->
  <bean id="geoServer" class="org.vfny.geoserver.global.GeoServer">
    <constructor-arg ref="config" />
  </bean>
  <bean id="globalConfig"
class="org.vfny.geoserver.config.GlobalConfig">
    <constructor-arg ref="geoServer" />
  </bean>

  <!-- data module -->
  <bean id="data" class="org.vfny.geoserver.global.Data">
    <constructor-arg ref="config" />
    <constructor-arg ref="geoServer" />
  </bean>
  <alias name="data" alias="catalog" />

  <bean id="dataConfig" class="org.vfny.geoserver.config.DataConfig">
    <constructor-arg ref="data" />
  </bean>

=================================================

WebApplictionContext.refresh() method fails during starting of the Spring
container because it calls ApplicationContext.destroy() methods of classes
that implement DisplosableBean interface like
org,vfny.geoserver.global.GeoServer class. destroy() method of the last one
tries to get a bean during destroying Spring container during refreshing
process, it causes an exception with Spring 2.5:

============================================================

19:34:16 ERROR [support.DisposableBeanAdapter] - Couldn't invoke destroy
method of bean with name 'geoServer'
org.springframework.beans.factory.BeanCreationNotAllowedException: Error
creating bean with name 'data': Singleton bean creation not allowed while
the singletons of this factory are in destruction (Do not request a bean
from a BeanFactory in a destroy method implementation!)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi
ngleton(DefaultSingletonBeanRegistry.java:156)
  at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:248)
  at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:170)
  at
org.springframework.context.support.AbstractApplicationContext.getBean(Abstr
actApplicationContext.java:883)
  at org.vfny.geoserver.global.GeoServer.destroy(GeoServer.java:1033)
  at
org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(Disp
osableBeanAdapter.java:154)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oyBean(DefaultSingletonBeanRegistry.java:397)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oySingleton(DefaultSingletonBeanRegistry.java:375)
  at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr
oySingletons(DefaultSingletonBeanRegistry.java:348)
  at
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr
actApplicationContext.java:377)

=====================================================================

The idea is to make GeoServer bean aware about Data by a local reference to
its instance or implement DisposableBean interface in Data class itself and
move functionality from GeoServer.destroy() to Data.destroy().

I have just started to test GeoServer 1.6.x with Spring 2.5 in the context
of our webapp architecture, may be there are other places that would be
desirable to make compatible with Spring 1.2.x and Spring 2.5.

Vitali Diatchkov.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I think the only reason for not upgrading was Acegi... but it definitely supports spring 2.0.x and 2.5.x. I guess the only other reason is "if it aint broke, don't fix it". But I agree... spring 1.x is pretty much officially archived (only available from the archives)... so it may be time to upgrade.

Chris Holmes wrote:

What are our reasons for not upgrading GeoServer to Spring 2.5? It seems like 1.2 is not all that supported any more, and that being on 2.5 might give us better compatibility with other projects? Plus if we have bugs they are more likely to get fixed - if we have a bug with 1.2 it'd be like people asking us to fix a bug in GS 1.3...

It seems like now would be a good time to do the upgrade on trunk, while it's still in beta.

Chris

Justin Deoliveira wrote:

Hi Vitali,

I too tried this before and ran into similar issues, but did not spend too much time looking into this.

I am creating a jira issue for this:

http://jira.codehaus.org/browse/GEOS-1831

Sooner or later we will officially move to Spring 2. When will be a community decision, but ironing out the issues before hand will not hurt.

-Justin

Vitali Diatchkov wrote:

Hello!

We are using GeoServer as a part of web application (several GeoServer's
modules: data, platform, main, ows,..). It serves as an engine to
load/persist features directly from/to their datastores and lets us to reuse
rich configuration of datastores and feature types in XML, gives direct
access to features without WFS XML request/response expenses and so on. But
the web application relies on the Spring 2.5 which is more strict then
1.2.x. Basic configuration of GeoServer beans looks like:

======================================================
    <!-- GeoServer configuration -->

    <!-- resources -->
    <bean id="resourceLoader"
class="org.geoserver.platform.GeoServerResourceLoader" />

    <!-- configuration module -->
    <bean id="config" class="org.vfny.geoserver.global.Config" />

    <!-- geoserver module -->
    <bean id="geoServer" class="org.vfny.geoserver.global.GeoServer">
        <constructor-arg ref="config" />
    </bean>
    <bean id="globalConfig"
class="org.vfny.geoserver.config.GlobalConfig">
        <constructor-arg ref="geoServer" />
    </bean>

    <!-- data module -->
    <bean id="data" class="org.vfny.geoserver.global.Data">
        <constructor-arg ref="config" />
        <constructor-arg ref="geoServer" />
    </bean>
    <alias name="data" alias="catalog" />

    <bean id="dataConfig" class="org.vfny.geoserver.config.DataConfig">
        <constructor-arg ref="data" />
    </bean>

=================================================

WebApplictionContext.refresh() method fails during starting of the Spring
container because it calls ApplicationContext.destroy() methods of classes
that implement DisplosableBean interface like
org,vfny.geoserver.global.GeoServer class. destroy() method of the last one
tries to get a bean during destroying Spring container during refreshing
process, it causes an exception with Spring 2.5:

============================================================

19:34:16 ERROR [support.DisposableBeanAdapter] - Couldn't invoke destroy
method of bean with name 'geoServer'
org.springframework.beans.factory.BeanCreationNotAllowedException: Error
creating bean with name 'data': Singleton bean creation not allowed while
the singletons of this factory are in destruction (Do not request a bean
from a BeanFactory in a destroy method implementation!)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi

ngleton(DefaultSingletonBeanRegistry.java:156)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra

ctBeanFactory.java:248)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra

ctBeanFactory.java:170)
    at
org.springframework.context.support.AbstractApplicationContext.getBean(Abstr

actApplicationContext.java:883)
    at org.vfny.geoserver.global.GeoServer.destroy(GeoServer.java:1033)
    at
org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(Disp

osableBeanAdapter.java:154)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr

oyBean(DefaultSingletonBeanRegistry.java:397)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr

oySingleton(DefaultSingletonBeanRegistry.java:375)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destr

oySingletons(DefaultSingletonBeanRegistry.java:348)
    at
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr

actApplicationContext.java:377)

=====================================================================

The idea is to make GeoServer bean aware about Data by a local reference to
its instance or implement DisposableBean interface in Data class itself and
move functionality from GeoServer.destroy() to Data.destroy().

I have just started to test GeoServer 1.6.x with Spring 2.5 in the context
of our webapp architecture, may be there are other places that would be
desirable to make compatible with Spring 1.2.x and Spring 2.5.

Vitali Diatchkov.

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

Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47eab5d7293215332866982!

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

!DSPAM:4007,47eab5d7293215332866982!

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

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47eab5d7293215332866982!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Justin Deoliveira ha scritto:

I think the only reason for not upgrading was Acegi... but it definitely supports spring 2.0.x and 2.5.x. I guess the only other reason is "if it aint broke, don't fix it".

Yep, that was me :wink:

But I agree... spring 1.x is pretty much officially archived (only available from the archives)... so it may be time to upgrade.

No problem with that, as Chris said, this is a golden time to try and
upgrade, no OGC related work ongoing on trunk, and still far from a
release, so we have plenty of time to fix any issue that may come up.

Cheers
Andrea

Cool. This may be worth a gsip? Or not? If so you want to make one Justin?

Andrea Aime wrote:

Justin Deoliveira ha scritto:

I think the only reason for not upgrading was Acegi... but it definitely supports spring 2.0.x and 2.5.x. I guess the only other reason is "if it aint broke, don't fix it".

Yep, that was me :wink:

But I agree... spring 1.x is pretty much officially archived (only available from the archives)... so it may be time to upgrade.

No problem with that, as Chris said, this is a golden time to try and
upgrade, no OGC related work ongoing on trunk, and still far from a
release, so we have plenty of time to fix any issue that may come up.

Cheers
Andrea

!DSPAM:4005,47eb4ebb166111637810514!

Not sure... I coudl throw one together but it would be pretty simple. Just a few dependency changes, and perhaps some testing, running cite and all that. What do others think? Is this GSIP worthy?

Chris Holmes wrote:

Cool. This may be worth a gsip? Or not? If so you want to make one Justin?

Andrea Aime wrote:

Justin Deoliveira ha scritto:

I think the only reason for not upgrading was Acegi... but it definitely supports spring 2.0.x and 2.5.x. I guess the only other reason is "if it aint broke, don't fix it".

Yep, that was me :wink:

But I agree... spring 1.x is pretty much officially archived (only available from the archives)... so it may be time to upgrade.

No problem with that, as Chris said, this is a golden time to try and
upgrade, no OGC related work ongoing on trunk, and still far from a
release, so we have plenty of time to fix any issue that may come up.

Cheers
Andrea

!DSPAM:4007,47ebaecc291074901796417!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Justin Deoliveira ha scritto:

Not sure... I coudl throw one together but it would be pretty simple. Just a few dependency changes, and perhaps some testing, running cite and all that. What do others think? Is this GSIP worthy?

Seems a little overkill to me? What about a simple vote on the mailing list?

Cheers
Andrea