[Geoserver-devel] Allow plugins to customize XStreamPersister

GeoServer GeoServer Developer
1

Hi,
when working over a new module there’s often a decision to be made, about where
the configuration should be stored and how.

While custom configuration files are a popular choice, they also have significant downsides:

  • the config in question cannot be edited via REST config
  • persistance has to be managed by the plugin
  • the config sometimes really is something related to a particular catalog resource, so it
    would be better placed as part of the resource metadata map

Of course one can put whatever is needed in the metadata map, but the default
XStream persistence can leave a lot to be desired, with package names included
in the element names and the like, to the point of making the metadata map choice
less than desirable.

What I’m proposing here is a simple customization to the XStreamPersister that
allows plugins to register converters and aliases for their objects.
This is probably needed by Sampo for the stored query configuration, and I would also
like to benefit from it.

The interface would be simple:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */
    void init(XStream xs);

}

This is pretty small, so not sure if a GSIP is required, but if you feel like it is,
let me know.

Feedback welcomed

Cheers
Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

2

+1 on the idea. Personally I am fine without a proposal for this one, I do have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself, or from XStreamPersisterFactory? I would vote for the latter as I think it would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the underlying xstream? Rationale is that since we expose some other methods on XStreamPersister that configure how things are encoded I wonder if we may want to make those (along with future methods) available to the plugins as well?

···

On Fri, Apr 18, 2014 at 3:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
when working over a new module there’s often a decision to be made, about where
the configuration should be stored and how.

While custom configuration files are a popular choice, they also have significant downsides:

  • the config in question cannot be edited via REST config
  • persistance has to be managed by the plugin
  • the config sometimes really is something related to a particular catalog resource, so it
    would be better placed as part of the resource metadata map

Of course one can put whatever is needed in the metadata map, but the default
XStream persistence can leave a lot to be desired, with package names included
in the element names and the like, to the point of making the metadata map choice
less than desirable.

What I’m proposing here is a simple customization to the XStreamPersister that
allows plugins to register converters and aliases for their objects.
This is probably needed by Sampo for the stored query configuration, and I would also
like to benefit from it.

The interface would be simple:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */
    void init(XStream xs);

}

This is pretty small, so not sure if a GSIP is required, but if you feel like it is,
let me know.

Feedback welcomed

Cheers
Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

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

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

3

+1. Thanks Andrea :slight_smile:

S.

···

On Sun, Apr 20, 2014 at 8:04 PM, Justin Deoliveira <jdeolive@anonymised.com…> wrote:

+1 on the idea. Personally I am fine without a proposal for this one, I do have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself, or from XStreamPersisterFactory? I would vote for the latter as I think it would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the underlying xstream? Rationale is that since we expose some other methods on XStreamPersister that configure how things are encoded I wonder if we may want to make those (along with future methods) available to the plugins as well?

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 18, 2014 at 3:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
when working over a new module there’s often a decision to be made, about where
the configuration should be stored and how.

While custom configuration files are a popular choice, they also have significant downsides:

  • the config in question cannot be edited via REST config
  • persistance has to be managed by the plugin
  • the config sometimes really is something related to a particular catalog resource, so it
    would be better placed as part of the resource metadata map

Of course one can put whatever is needed in the metadata map, but the default
XStream persistence can leave a lot to be desired, with package names included
in the element names and the like, to the point of making the metadata map choice
less than desirable.

What I’m proposing here is a simple customization to the XStreamPersister that
allows plugins to register converters and aliases for their objects.
This is probably needed by Sampo for the stored query configuration, and I would also
like to benefit from it.

The interface would be simple:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */
    void init(XStream xs);

}

This is pretty small, so not sure if a GSIP is required, but if you feel like it is,
let me know.

Feedback welcomed

Cheers
Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

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

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

4

On Sun, Apr 20, 2014 at 7:04 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

+1 on the idea. Personally I am fine without a proposal for this one, I do
have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself,
or from XStreamPersisterFactory? I would vote for the latter as I think it
would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the
underlying xstream? Rationale is that since we expose some other methods on
XStreamPersister that configure how things are encoded I wonder if we may
want to make those (along with future methods) available to the plugins as
well?

Sounds good to me, in this case the interface becomes:

XStreamPersisterInitializer {

  /**
   * Allows XStream customizations. Plugins can use this to add aliases and
   * custom converters for their own configuration objects
   */
  void init(XStreamPersister persister);

}

and it will be called in both methods of XStreamPersisterFactory before
returning a XStreamPersister
to the caller.

I've created a pull request with the above and a test, and discovered it's
actually better than was I proposed for my own
needs, as I also needed to register the bean with the brief map handling to
make things work:
https://github.com/geoserver/geoserver/pull/571

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

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

5

Hi,

This looks pretty straightforward. To implement this, I guess I would have to do the following

  1. Create an extension module under geoserver for wfs-ng (there’s no such extensionsion yet)
  2. Have that extension depend on gt-wfs-ng
  3. Include code in the extension which registers the XStreamPersisters required

The code in 3. would serialize & deserialize the configuration objects. This glue would need to live in the geoserver extension as XStreamPersister is part of gs, not gt. The actual configuration objects would be part of gs-wfs-ng.

Is configuring the XStreamPersisterInitializer impl as a spring bean enough to get the initializer registered?

What about name collision? This mechanism seems to register all XStreamPersisterInitializers for all XStream persisters. Isn’t there a danger that an extension might register a name already in use for another extension?

S.
···

On Tue, Apr 22, 2014 at 2:46 PM, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Sun, Apr 20, 2014 at 7:04 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

+1 on the idea. Personally I am fine without a proposal for this one, I do have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself, or from XStreamPersisterFactory? I would vote for the latter as I think it would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the underlying xstream? Rationale is that since we expose some other methods on XStreamPersister that configure how things are encoded I wonder if we may want to make those (along with future methods) available to the plugins as well?

Sounds good to me, in this case the interface becomes:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */

void init(XStreamPersister persister);

}

and it will be called in both methods of XStreamPersisterFactory before returning a XStreamPersister
to the caller.

I’ve created a pull request with the above and a test, and discovered it’s actually better than was I proposed for my own
needs, as I also needed to register the bean with the brief map handling to make things work:
https://github.com/geoserver/geoserver/pull/571

Cheers

Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

6

On Tue, Apr 22, 2014 at 3:10 PM, Sampo Savolainen <
sampo.savolainen@anonymised.com> wrote:

The code in 3. would serialize & deserialize the configuration objects.
This glue would need to live in the geoserver extension as XStreamPersister
is part of gs, not gt. The actual configuration objects would be part of
gs-wfs-ng.

.. would be part of gt-wfs-ng, of course.

--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

7

On Tue, Apr 22, 2014 at 2:10 PM, Sampo Savolainen <
sampo.savolainen@anonymised.com> wrote:

Hi,

This looks pretty straightforward. To implement this, I guess I would have
to do the following
1. Create an extension module under geoserver for wfs-ng (there's no such
extensionsion yet)
2. Have that extension depend on gt-wfs-ng
3. Include code in the extension which registers the XStreamPersisters
required

The code in 3. would serialize & deserialize the configuration objects.
This glue would need to live in the geoserver extension as XStreamPersister
is part of gs, not gt. The actual configuration objects would be part of
gs-wfs-ng.

Correct, pretty much like for VirtualTable in JDBC land. I guess you might
need one extension point more to configure the
types in the store, like we do for VirtualTable in ResourcePool

Is configuring the XStreamPersisterInitializer impl as a spring bean
enough to get the initializer registered?

It shoul.d

What about name collision? This mechanism seems to register all
XStreamPersisterInitializers for all XStream persisters. Isn't there a
danger that an extension might register a name already in use for another
extension?

There is, but it has never been a problem so far, people just pay attention
to provide unique enough names in
the spring context (it's not like geoserver has 100s of plugins)

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

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

8

Hi Justin,
not sure if you saw the pull request already, I’ve mentioned in a mail in this
thread a few days ago:
https://github.com/geoserver/geoserver/pull/571

Seems good to go to me

Cheers
Andrea

···

On Sun, Apr 20, 2014 at 7:04 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

+1 on the idea. Personally I am fine without a proposal for this one, I do have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself, or from XStreamPersisterFactory? I would vote for the latter as I think it would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the underlying xstream? Rationale is that since we expose some other methods on XStreamPersister that configure how things are encoded I wonder if we may want to make those (along with future methods) available to the plugins as well?

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

On Fri, Apr 18, 2014 at 3:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
when working over a new module there’s often a decision to be made, about where
the configuration should be stored and how.

While custom configuration files are a popular choice, they also have significant downsides:

  • the config in question cannot be edited via REST config
  • persistance has to be managed by the plugin
  • the config sometimes really is something related to a particular catalog resource, so it
    would be better placed as part of the resource metadata map

Of course one can put whatever is needed in the metadata map, but the default
XStream persistence can leave a lot to be desired, with package names included
in the element names and the like, to the point of making the metadata map choice
less than desirable.

What I’m proposing here is a simple customization to the XStreamPersister that
allows plugins to register converters and aliases for their objects.
This is probably needed by Sampo for the stored query configuration, and I would also
like to benefit from it.

The interface would be simple:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */
    void init(XStream xs);

}

This is pretty small, so not sure if a GSIP is required, but if you feel like it is,
let me know.

Feedback welcomed

Cheers
Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

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

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

9

Looks good to me.

···

On Thu, Apr 24, 2014 at 10:33 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Justin,
not sure if you saw the pull request already, I’ve mentioned in a mail in this
thread a few days ago:
https://github.com/geoserver/geoserver/pull/571

Seems good to go to me

Cheers

Andrea

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

On Sun, Apr 20, 2014 at 7:04 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

+1 on the idea. Personally I am fine without a proposal for this one, I do have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself, or from XStreamPersisterFactory? I would vote for the latter as I think it would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the underlying xstream? Rationale is that since we expose some other methods on XStreamPersister that configure how things are encoded I wonder if we may want to make those (along with future methods) available to the plugins as well?

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

On Fri, Apr 18, 2014 at 3:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
when working over a new module there’s often a decision to be made, about where
the configuration should be stored and how.

While custom configuration files are a popular choice, they also have significant downsides:

  • the config in question cannot be edited via REST config
  • persistance has to be managed by the plugin
  • the config sometimes really is something related to a particular catalog resource, so it
    would be better placed as part of the resource metadata map

Of course one can put whatever is needed in the metadata map, but the default
XStream persistence can leave a lot to be desired, with package names included
in the element names and the like, to the point of making the metadata map choice
less than desirable.

What I’m proposing here is a simple customization to the XStreamPersister that
allows plugins to register converters and aliases for their objects.
This is probably needed by Sampo for the stored query configuration, and I would also
like to benefit from it.

The interface would be simple:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */
    void init(XStream xs);

}

This is pretty small, so not sure if a GSIP is required, but if you feel like it is,
let me know.

Feedback welcomed

Cheers
Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

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

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

10

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

…

25 Apr 09:03:46 INFO [org.geoserver] - Loaded feature type ‘restricted’, enabled
25 Apr 09:03:46 INFO [org.geoserver] - Loaded feature type ‘sf’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer ‘restricted’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer group ‘tiger-ny’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer group ‘spearfish’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer group ‘tasmania’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded service ‘wcs’, enabled
25 Apr 09:03:46 INFO [org.geoserver] - Loaded service ‘wfs’, enabled
25 Apr 09:03:46 INFO [org.geoserver] - Loaded service ‘wms’, enabled
25 Apr 09:03:46 INFO [storage.DefaultStorageFinder] - ***************************************************************************************
25 Apr 09:03:46 INFO [storage.DefaultStorageFinder] - *** Reverting to java.io.tmpdir null for storage. Please set GEOWEBCACHE_CACHE_DIR. ***
25 Apr 09:03:46 INFO [storage.DefaultStorageFinder] - ***************************************************************************************
25 Apr 09:03:46 INFO [config.XMLConfiguration] - Will look for geowebcache.xml in ‘/tmp/geowebcache’
25 Apr 09:03:47 INFO [gwc.config] - Initializing GeoServer specific GWC configuration from gwc-gs.xml
#################### WfsNgXStreamPersisterInitializer init(XStreamPersister) called

…

(The ##### line is System.err from my persister bean)

I would’ve expected the persister to be initialized before the feature types are loaded? Also, the metadata configuration XML is not being deserialized as is.

Sampo

···

On Fri, Apr 25, 2014 at 12:14 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Looks good to me.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Thu, Apr 24, 2014 at 10:33 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Justin,
not sure if you saw the pull request already, I’ve mentioned in a mail in this
thread a few days ago:
https://github.com/geoserver/geoserver/pull/571

Seems good to go to me

Cheers

Andrea

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

On Sun, Apr 20, 2014 at 7:04 PM, Justin Deoliveira <jdeolive@anonymised.com9…> wrote:

+1 on the idea. Personally I am fine without a proposal for this one, I do have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself, or from XStreamPersisterFactory? I would vote for the latter as I think it would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the underlying xstream? Rationale is that since we expose some other methods on XStreamPersister that configure how things are encoded I wonder if we may want to make those (along with future methods) available to the plugins as well?

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

On Fri, Apr 18, 2014 at 3:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
when working over a new module there’s often a decision to be made, about where
the configuration should be stored and how.

While custom configuration files are a popular choice, they also have significant downsides:

  • the config in question cannot be edited via REST config
  • persistance has to be managed by the plugin
  • the config sometimes really is something related to a particular catalog resource, so it
    would be better placed as part of the resource metadata map

Of course one can put whatever is needed in the metadata map, but the default
XStream persistence can leave a lot to be desired, with package names included
in the element names and the like, to the point of making the metadata map choice
less than desirable.

What I’m proposing here is a simple customization to the XStreamPersister that
allows plugins to register converters and aliases for their objects.
This is probably needed by Sampo for the stored query configuration, and I would also
like to benefit from it.

The interface would be simple:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */
    void init(XStream xs);

}

This is pretty small, so not sure if a GSIP is required, but if you feel like it is,
let me know.

Feedback welcomed

Cheers
Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

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

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

11

Hi,

This seems to be happening because the plugin is not initialized early enough. For some reason it’s loaded with GWC but not at the beginning of the server setup. Maybe I’ve missed a configuration file that informs GS about possible extensions?

Sampo

···

On Fri, Apr 25, 2014 at 9:08 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

…

25 Apr 09:03:46 INFO [org.geoserver] - Loaded feature type ‘restricted’, enabled
25 Apr 09:03:46 INFO [org.geoserver] - Loaded feature type ‘sf’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer ‘restricted’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer group ‘tiger-ny’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer group ‘spearfish’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded layer group ‘tasmania’
25 Apr 09:03:46 INFO [org.geoserver] - Loaded service ‘wcs’, enabled
25 Apr 09:03:46 INFO [org.geoserver] - Loaded service ‘wfs’, enabled
25 Apr 09:03:46 INFO [org.geoserver] - Loaded service ‘wms’, enabled
25 Apr 09:03:46 INFO [storage.DefaultStorageFinder] - ***************************************************************************************
25 Apr 09:03:46 INFO [storage.DefaultStorageFinder] - *** Reverting to java.io.tmpdir null for storage. Please set GEOWEBCACHE_CACHE_DIR. ***
25 Apr 09:03:46 INFO [storage.DefaultStorageFinder] - ***************************************************************************************
25 Apr 09:03:46 INFO [config.XMLConfiguration] - Will look for geowebcache.xml in ‘/tmp/geowebcache’
25 Apr 09:03:47 INFO [gwc.config] - Initializing GeoServer specific GWC configuration from gwc-gs.xml
#################### WfsNgXStreamPersisterInitializer init(XStreamPersister) called

…

(The ##### line is System.err from my persister bean)

I would’ve expected the persister to be initialized before the feature types are loaded? Also, the metadata configuration XML is not being deserialized as is.

Sampo

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 12:14 AM, Justin Deoliveira <jdeolive@anonymised.com3839…> wrote:

Looks good to me.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Thu, Apr 24, 2014 at 10:33 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Justin,
not sure if you saw the pull request already, I’ve mentioned in a mail in this
thread a few days ago:
https://github.com/geoserver/geoserver/pull/571

Seems good to go to me

Cheers

Andrea

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

On Sun, Apr 20, 2014 at 7:04 PM, Justin Deoliveira <jdeolive@anonymised.com9…> wrote:

+1 on the idea. Personally I am fine without a proposal for this one, I do have a couple of questions though.

Where will the extension point be invoked from? XStreamPersister itself, or from XStreamPersisterFactory? I would vote for the latter as I think it would be nice to keep that outside of the persister itself.

Should the interface take an instance of the persister rather than the underlying xstream? Rationale is that since we expose some other methods on XStreamPersister that configure how things are encoded I wonder if we may want to make those (along with future methods) available to the plugins as well?

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

On Fri, Apr 18, 2014 at 3:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
when working over a new module there’s often a decision to be made, about where
the configuration should be stored and how.

While custom configuration files are a popular choice, they also have significant downsides:

  • the config in question cannot be edited via REST config
  • persistance has to be managed by the plugin
  • the config sometimes really is something related to a particular catalog resource, so it
    would be better placed as part of the resource metadata map

Of course one can put whatever is needed in the metadata map, but the default
XStream persistence can leave a lot to be desired, with package names included
in the element names and the like, to the point of making the metadata map choice
less than desirable.

What I’m proposing here is a simple customization to the XStreamPersister that
allows plugins to register converters and aliases for their objects.
This is probably needed by Sampo for the stored query configuration, and I would also
like to benefit from it.

The interface would be simple:

XStreamPersisterInitializer {

/**

  • Allows XStream customizations. Plugins can use this to add aliases and
  • custom converters for their own configuration objects
    */
    void init(XStream xs);

}

This is pretty small, so not sure if a GSIP is required, but if you feel like it is,
let me know.

Feedback welcomed

Cheers
Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

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

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

12

On Fri, Apr 25, 2014 at 8:08 AM, Sampo Savolainen <
sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup,
the XStreamPersisterInitializer.init() method is called only after the
server configuration is loaded.

Hum, I've indeed noticed yesterday that some bits of code in GeoServer
instantiate the persister factory
programatically instead of fetching it from the application context, that
might be the reason.
I believe it can be fixed by having them use Spring injection instead

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

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

13

Hi,

I’ve looked at this further. For some strange reason, the gs-wfs-ng extension applicationContext is loaded only inside GWCConfigPersister.loadConfig(). Do you know of an extension which is for sure initialized before parsing configuration? Maybe I’m missing some configuration magic.

S.

···

On Fri, Apr 25, 2014 at 9:38 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 8:08 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

Hum, I’ve indeed noticed yesterday that some bits of code in GeoServer instantiate the persister factory
programatically instead of fetching it from the application context, that might be the reason.
I believe it can be fixed by having them use Spring injection instead

Cheers

Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

14

Oops. Scratch that. It’s loaded before GWCConfigPersister. I was missing a breakpoint I thought I had set up :slight_smile:

Nevertheless, it’s loaded too late.

S.

···

On Fri, Apr 25, 2014 at 9:42 AM, Sampo Savolainen <sampo.savolainen@anonymised.com3889…> wrote:

Hi,

I’ve looked at this further. For some strange reason, the gs-wfs-ng extension applicationContext is loaded only inside GWCConfigPersister.loadConfig(). Do you know of an extension which is for sure initialized before parsing configuration? Maybe I’m missing some configuration magic.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:38 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com89…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 8:08 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

Hum, I’ve indeed noticed yesterday that some bits of code in GeoServer instantiate the persister factory
programatically instead of fetching it from the application context, that might be the reason.
I believe it can be fixed by having them use Spring injection instead

Cheers

Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

15

There are multiple points in GS code where XStreamPersisterFactories are created using the raw constructor. This results in the setApplicationContext() method not being called in most cases. This configuration model works only when the XStreamPersisterFactory is instantiated via Spring.

Any ideas?

S.

···

On Fri, Apr 25, 2014 at 9:44 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Oops. Scratch that. It’s loaded before GWCConfigPersister. I was missing a breakpoint I thought I had set up :slight_smile:

Nevertheless, it’s loaded too late.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:42 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I’ve looked at this further. For some strange reason, the gs-wfs-ng extension applicationContext is loaded only inside GWCConfigPersister.loadConfig(). Do you know of an extension which is for sure initialized before parsing configuration? Maybe I’m missing some configuration magic.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:38 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 8:08 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

Hum, I’ve indeed noticed yesterday that some bits of code in GeoServer instantiate the persister factory
programatically instead of fetching it from the application context, that might be the reason.
I believe it can be fixed by having them use Spring injection instead

Cheers

Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

16

Ok. This is a bit ugly, but seems to work for me:

In org.geoserver.config.GeoServerLoader:

public void setApplicationContext(ApplicationContext applicationContext)
throws BeansException {
xpf.setApplicationContext(applicationContext);
}

The method already exists but was empty. Passing the application context to the parser does activate the initializer. It’s more of a band-aid though, the real problem is that GS is not 100% spring managed.

S.

···

On Fri, Apr 25, 2014 at 9:55 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

There are multiple points in GS code where XStreamPersisterFactories are created using the raw constructor. This results in the setApplicationContext() method not being called in most cases. This configuration model works only when the XStreamPersisterFactory is instantiated via Spring.

Any ideas?

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:44 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Oops. Scratch that. It’s loaded before GWCConfigPersister. I was missing a breakpoint I thought I had set up :slight_smile:

Nevertheless, it’s loaded too late.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:42 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I’ve looked at this further. For some strange reason, the gs-wfs-ng extension applicationContext is loaded only inside GWCConfigPersister.loadConfig(). Do you know of an extension which is for sure initialized before parsing configuration? Maybe I’m missing some configuration magic.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:38 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 8:08 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

Hum, I’ve indeed noticed yesterday that some bits of code in GeoServer instantiate the persister factory
programatically instead of fetching it from the application context, that might be the reason.
I believe it can be fixed by having them use Spring injection instead

Cheers

Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

17

Hi Sampo,
I’ve just merged the changes, and added modifications to make the initializers be picked up regardless of
whether the factory was created via spring or programatically: there were just too many places using
it programatically, so I went for a GeoServerExtensions.extensions(…) call instead (the version that
does not take the spring context as an argument, but uses the one set in GeoServerExtensions itself

Cheers
Andrea

···

On Fri, Apr 25, 2014 at 9:06 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Ok. This is a bit ugly, but seems to work for me:

In org.geoserver.config.GeoServerLoader:

public void setApplicationContext(ApplicationContext applicationContext)
throws BeansException {
xpf.setApplicationContext(applicationContext);
}

The method already exists but was empty. Passing the application context to the parser does activate the initializer. It’s more of a band-aid though, the real problem is that GS is not 100% spring managed.

S.

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

On Fri, Apr 25, 2014 at 9:55 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

There are multiple points in GS code where XStreamPersisterFactories are created using the raw constructor. This results in the setApplicationContext() method not being called in most cases. This configuration model works only when the XStreamPersisterFactory is instantiated via Spring.

Any ideas?

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:44 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Oops. Scratch that. It’s loaded before GWCConfigPersister. I was missing a breakpoint I thought I had set up :slight_smile:

Nevertheless, it’s loaded too late.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:42 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I’ve looked at this further. For some strange reason, the gs-wfs-ng extension applicationContext is loaded only inside GWCConfigPersister.loadConfig(). Do you know of an extension which is for sure initialized before parsing configuration? Maybe I’m missing some configuration magic.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:38 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 8:08 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

Hum, I’ve indeed noticed yesterday that some bits of code in GeoServer instantiate the persister factory
programatically instead of fetching it from the application context, that might be the reason.
I believe it can be fixed by having them use Spring injection instead

Cheers

Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

18

Hi Andrea,

Thanks for this. I’ll merge my branch with these changes. I trust the second commit in your pull request branch (https://github.com/aaime/geoserver/commit/d26ff665202d63e41e43c4f58c54768bd0a45576) contains all relevant changes, and I’ll merge them to my branch.

Sampo

···

On Wed, May 7, 2014 at 1:56 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Sampo,
I’ve just merged the changes, and added modifications to make the initializers be picked up regardless of
whether the factory was created via spring or programatically: there were just too many places using
it programatically, so I went for a GeoServerExtensions.extensions(…) call instead (the version that
does not take the spring context as an argument, but uses the one set in GeoServerExtensions itself

Cheers

Andrea

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:06 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Ok. This is a bit ugly, but seems to work for me:

In org.geoserver.config.GeoServerLoader:

public void setApplicationContext(ApplicationContext applicationContext)
throws BeansException {
xpf.setApplicationContext(applicationContext);
}

The method already exists but was empty. Passing the application context to the parser does activate the initializer. It’s more of a band-aid though, the real problem is that GS is not 100% spring managed.

S.

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

On Fri, Apr 25, 2014 at 9:55 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

There are multiple points in GS code where XStreamPersisterFactories are created using the raw constructor. This results in the setApplicationContext() method not being called in most cases. This configuration model works only when the XStreamPersisterFactory is instantiated via Spring.

Any ideas?

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:44 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Oops. Scratch that. It’s loaded before GWCConfigPersister. I was missing a breakpoint I thought I had set up :slight_smile:

Nevertheless, it’s loaded too late.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:42 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

I’ve looked at this further. For some strange reason, the gs-wfs-ng extension applicationContext is loaded only inside GWCConfigPersister.loadConfig(). Do you know of an extension which is for sure initialized before parsing configuration? Maybe I’m missing some configuration magic.

S.

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 9:38 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Fri, Apr 25, 2014 at 8:08 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Andrea,

I just merged this into my branch. It seems that during geoserver startup, the XStreamPersisterInitializer.init() method is called only after the server configuration is loaded.

Hum, I’ve indeed noticed yesterday that some bits of code in GeoServer instantiate the persister factory
programatically instead of fetching it from the application context, that might be the reason.
I believe it can be fixed by having them use Spring injection instead

Cheers

Andrea

–

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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