[Geoserver-devel] Migration plan for wfs-ng

GeoServer GeoServer Developer
1

Hey folks,

With Niels last pull request for wfs-ng adding the requested tests I believe all the feedback has been addressed regarding a transition to wfs-ng. So I wanted to start hashing out the plan to migrate.

At the moment there are some core dependencies on the WFSDataStoreFactory class from the old module, which lives in the package org.geotools.data.wfs. Currently the ng factory lives in the package org.geoserver.data.wfs.impl, which is kind of strange to have a public interface in an impl package.

If we moved the ng factory into the data.wfs package at which point we don’t have to change a line of geoserver code in order to use it. However this would mean that the new and the old datastore couldn’t co-exist at the same time.

A few options I can think of.

  1. Allow the two modules to co-exist on the classpath. This approach I think would be the most work because we would have to:

a. come up with a way for the factories to know about one another
b. make the code in geoserver dynamically access one or the other, or continue to use the old datastore for the remove ows support, and the new one for datastore access.

  1. Make wfs-ng a compile time drop-in and package wfs-ng as an extension and let the users know that if they want to use it they have to remove the old jar first.

  2. Rename wfs-ng to wfs (using a different group name to avoid a maven conflict) and package as an extension. When the user installs it it will overwrite the old version.

Thoughts?

–

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

2

On Fri, Jun 13, 2014 at 8:39 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Hey folks,

With Niels last pull request for wfs-ng adding the requested tests I
believe all the feedback has been addressed regarding a transition to
wfs-ng. So I wanted to start hashing out the plan to migrate.

At the moment there are some core dependencies on the WFSDataStoreFactory
class from the old module, which lives in the package
org.geotools.data.wfs. Currently the ng factory lives in the package
org.geoserver.data.wfs.impl, which is kind of strange to have a public
interface in an impl package.

If we moved the ng factory into the data.wfs package at which point we
don't have to change a line of geoserver code in order to use it. However
this would mean that the new and the old datastore couldn't co-exist at the
same time.

A few options I can think of.

1. Allow the two modules to co-exist on the classpath. This approach I
think would be the most work because we would have to:

  a. come up with a way for the factories to know about one another
  b. make the code in geoserver dynamically access one or the other, or
continue to use the old datastore for the remove ows support, and the new
one for datastore access.

2. Make wfs-ng a compile time drop-in and package wfs-ng as an extension
and let the users know that if they want to use it they have to remove the
old jar first.

3. Rename wfs-ng to wfs (using a different group name to avoid a maven
conflict) and package as an extension. When the user installs it it will
overwrite the old version.

4. Make wfs-ng a compile time drop-in and package wfs as an extension and
let the users know that if they want to use it they have to remove the new
jar first.
Too ambitious?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

3

On Fri, Jun 13, 2014 at 2:53 PM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Fri, Jun 13, 2014 at 8:39 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Hey folks,

With Niels last pull request for wfs-ng adding the requested tests I
believe all the feedback has been addressed regarding a transition to
wfs-ng. So I wanted to start hashing out the plan to migrate.

At the moment there are some core dependencies on the WFSDataStoreFactory
class from the old module, which lives in the package
org.geotools.data.wfs. Currently the ng factory lives in the package
org.geoserver.data.wfs.impl, which is kind of strange to have a public
interface in an impl package.

If we moved the ng factory into the data.wfs package at which point we
don't have to change a line of geoserver code in order to use it. However
this would mean that the new and the old datastore couldn't co-exist at the
same time.

A few options I can think of.

1. Allow the two modules to co-exist on the classpath. This approach I
think would be the most work because we would have to:

  a. come up with a way for the factories to know about one another
  b. make the code in geoserver dynamically access one or the other, or
continue to use the old datastore for the remove ows support, and the new
one for datastore access.

2. Make wfs-ng a compile time drop-in and package wfs-ng as an extension
and let the users know that if they want to use it they have to remove the
old jar first.

3. Rename wfs-ng to wfs (using a different group name to avoid a maven
conflict) and package as an extension. When the user installs it it will
overwrite the old version.

4. Make wfs-ng a compile time drop-in and package wfs as an extension and
let the users know that if they want to use it they have to remove the new
jar first.
Too ambitious?

Well to be honest based on my testing the new extension worked better, I

wasn't able to render any cascaded layers via WMS (might have been missing
some options) so at first thought I would be ok with this option. I would
feel better if another geoserver or user , perhaps one who deals with the
cascaded wfs use case more than I do would try it out.

Cheers

Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive&gt;

4

On Mon, Jun 16, 2014 at 4:16 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

4. Make wfs-ng a compile time drop-in and package wfs as an extension and

let the users know that if they want to use it they have to remove the new
jar first.
Too ambitious?

Well to be honest based on my testing the new extension worked better, I

wasn't able to render any cascaded layers via WMS (might have been missing
some options) so at first thought I would be ok with this option. I would
feel better if another geoserver or user , perhaps one who deals with the
cascaded wfs use case more than I do would try it out.

Right. I'd like to help, but I won't be able to in the current week and
next, as I'm closing down
as much work as I can before going away one week for vacation, next week.
If no one else can, I'll be please to give it a spin when I come back.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

On Tue, Jun 17, 2014 at 3:48 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Mon, Jun 16, 2014 at 4:16 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

4. Make wfs-ng a compile time drop-in and package wfs as an extension and

let the users know that if they want to use it they have to remove the new
jar first.
Too ambitious?

Well to be honest based on my testing the new extension worked better, I

wasn't able to render any cascaded layers via WMS (might have been missing
some options) so at first thought I would be ok with this option. I would
feel better if another geoserver or user , perhaps one who deals with the
cascaded wfs use case more than I do would try it out.

Right. I'd like to help, but I won't be able to in the current week and
next, as I'm closing down
as much work as I can before going away one week for vacation, next week.
If no one else can, I'll be please to give it a spin when I come back.

Cool, I think for now what I'll do is proceed with making wfs-ng a pure
drop in and package it up as a community module for geoserver. Along with
it documentation that specifies installing it requires removing the old
one**. And then once we are more confident with it and it has seen some
more user testing we can perhaps perform the switch and make it the
default, packaging up the original as an extension.

** Side question: Rather than have the user remove files manually how about
making the artifact id's the same. So "wfs-ng" -> "wfs" and instead
distinguish the two with different group names?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

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

--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive&gt;

6

** Side question: Rather than have the user remove files manually how
about making the artifact id's the same. So "wfs-ng" -> "wfs" and instead
distinguish the two with different group names?

That would be better, may end up with a few leftover dependencies but I do
not see how that can cause harm.

We can also make the factory for "old" implementation do a Class forName
lookup for the new implementation - and refuse to be available if both are
present.
--
Jody

7

On Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Cool, I think for now what I'll do is proceed with making wfs-ng a pure
drop in and package it up as a community module for geoserver. Along with
it documentation that specifies installing it requires removing the old
one**. And then once we are more confident with it and it has seen some
more user testing we can perhaps perform the switch and make it the
default, packaging up the original as an extension.

No objection personally, but I'm wondering how that will affect Sampo's
work.
I supposedhis pull request won't even compile if we are not depending on
wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

···

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.

9

We do not have that many references to these constants, consider using “inline” with a TODO comment to switch it back after the migration is complete. Has the advantage of being easy/quick.

···

Jody Garnett

On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

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

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.

10

Hi,

By “constants”, were you referring to the parameter classes? The classes I’m talking about are proper real live classes which are used to configure how stored query parameters are derived from the query. These are much more complex than constants.

Sampo

···

On Mon, Jun 23, 2014 at 12:28 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We do not have that many references to these constants, consider using “inline” with a TODO comment to switch it back after the migration is complete. Has the advantage of being easy/quick.

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

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

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.

11

Let me check…

Factory is used in:

  • RemoteOWSTestSupport: Just a test so it can have a direct dependency. Checking the details the factory is used both directly and for the parameter keys. No reason not to inline the keys and use datastore finder

  • GetMapKvpRequestReader: same deal, used for parameter keys and could be replaced

WFSDataStore interface: not used directly in GeoServer
WFS_1_0_0_DataStore: not used directly in GeoServer

WFS_1_1_0_DataStore: not used directly in GeoServer

WFSTransactionState: not used directly by GeoServer

So perhaps you can be more specific?

···

Jody Garnett

On Mon, Jun 23, 2014 at 3:51 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

By “constants”, were you referring to the parameter classes? The classes I’m talking about are proper real live classes which are used to configure how stored query parameters are derived from the query. These are much more complex than constants.

Sampo

On Mon, Jun 23, 2014 at 12:28 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We do not have that many references to these constants, consider using “inline” with a TODO comment to switch it back after the migration is complete. Has the advantage of being easy/quick.

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

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

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.

12

Hi,

The configuration for a cascaded stored query specifies how the parameters for a cascaded request are mapped from viewparams (as SQL views), defaults, and the context of the original query (query envelope, for example).

So a layer created from a cascaded stored query might define:
"The value of parameter X is defined as (‘minimum X value of query envelope’ + ‘maximum X value of query envelope’) / 2 "
"The value of parameter Z is ‘foo’ "

This is done via the classes in my tree of gt-wfs-ng, package org.geotools.data.wfs.internal.v2_0.storedquery. These classes are persisted in featuretype.xml and the configuration is set up in the UI, so the classes must be available (somehow) for the UI to work. As the classes are in gt-wfs-ng, the requirement that geoserver work with either gt-wfs or gt-wfs-ng plugged in, is a big problem.

Does this help or are we talking about different things?

Sampo

···

On Mon, Jun 23, 2014 at 9:47 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Let me check…

Factory is used in:

  • RemoteOWSTestSupport: Just a test so it can have a direct dependency. Checking the details the factory is used both directly and for the parameter keys. No reason not to inline the keys and use datastore finder

  • GetMapKvpRequestReader: same deal, used for parameter keys and could be replaced

WFSDataStore interface: not used directly in GeoServer
WFS_1_0_0_DataStore: not used directly in GeoServer

WFS_1_1_0_DataStore: not used directly in GeoServer

WFSTransactionState: not used directly by GeoServer

So perhaps you can be more specific?

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 3:51 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

By “constants”, were you referring to the parameter classes? The classes I’m talking about are proper real live classes which are used to configure how stored query parameters are derived from the query. These are much more complex than constants.

Sampo

On Mon, Jun 23, 2014 at 12:28 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We do not have that many references to these constants, consider using “inline” with a TODO comment to switch it back after the migration is complete. Has the advantage of being easy/quick.

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

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

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.

13

We may be talking about different things, I am talking about datastore connection parameter constants defined in WFSDataStoreFactory. They are explicitly referenced via an import statement in a couple GeoServer files. For the current use of WFSDataStore we would be able to inline these values.

It sounds like a dependency to wfs-ng is needed for your branch. Are your parameters part of DataStore construction or are they additional Query parameters?

···

Jody Garnett

On Mon, Jun 23, 2014 at 4:59 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

The configuration for a cascaded stored query specifies how the parameters for a cascaded request are mapped from viewparams (as SQL views), defaults, and the context of the original query (query envelope, for example).

So a layer created from a cascaded stored query might define:
"The value of parameter X is defined as (‘minimum X value of query envelope’ + ‘maximum X value of query envelope’) / 2 "
"The value of parameter Z is ‘foo’ "

This is done via the classes in my tree of gt-wfs-ng, package org.geotools.data.wfs.internal.v2_0.storedquery. These classes are persisted in featuretype.xml and the configuration is set up in the UI, so the classes must be available (somehow) for the UI to work. As the classes are in gt-wfs-ng, the requirement that geoserver work with either gt-wfs or gt-wfs-ng plugged in, is a big problem.

Does this help or are we talking about different things?

Sampo

On Mon, Jun 23, 2014 at 9:47 AM, Jody Garnett <jody.garnett@anonymised.com03…> wrote:

Let me check…

Factory is used in:

  • RemoteOWSTestSupport: Just a test so it can have a direct dependency. Checking the details the factory is used both directly and for the parameter keys. No reason not to inline the keys and use datastore finder

  • GetMapKvpRequestReader: same deal, used for parameter keys and could be replaced

WFSDataStore interface: not used directly in GeoServer
WFS_1_0_0_DataStore: not used directly in GeoServer

WFS_1_1_0_DataStore: not used directly in GeoServer

WFSTransactionState: not used directly by GeoServer

So perhaps you can be more specific?

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 3:51 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

By “constants”, were you referring to the parameter classes? The classes I’m talking about are proper real live classes which are used to configure how stored query parameters are derived from the query. These are much more complex than constants.

Sampo

On Mon, Jun 23, 2014 at 12:28 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We do not have that many references to these constants, consider using “inline” with a TODO comment to switch it back after the migration is complete. Has the advantage of being easy/quick.

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

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

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.

14

Hi Jody,

Yes, we’ve managed to talk about different things. The parameters I’m talking about are not parameters for the data store, but configuration classes that dictate how cascaded stored queries are executed. For every layer based on cascaded stored queries, there is configuration relatively similar to SQL views. In this case, the configure defines what Stored Query Parameters are sent via each cascaded request. This method can be used to define both static and dynamic values for the parameters (via CQL expressions).

The parameters are stored in featuretype.xml as layer metadata and are passed on as query hints (as with SQL views). The data store then reads these hints and uses them, the query and user supplied viewparams to construct the parameters sent with the stored query request.

Like I mentioned earlier, the classes are needed in geoserver so the UI may manipulate these objects (and serialize/deserialize objects from the data directory).

S.

···

On Mon, Jun 23, 2014 at 10:15 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We may be talking about different things, I am talking about datastore connection parameter constants defined in WFSDataStoreFactory. They are explicitly referenced via an import statement in a couple GeoServer files. For the current use of WFSDataStore we would be able to inline these values.

It sounds like a dependency to wfs-ng is needed for your branch. Are your parameters part of DataStore construction or are they additional Query parameters?

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 4:59 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

The configuration for a cascaded stored query specifies how the parameters for a cascaded request are mapped from viewparams (as SQL views), defaults, and the context of the original query (query envelope, for example).

So a layer created from a cascaded stored query might define:
"The value of parameter X is defined as (‘minimum X value of query envelope’ + ‘maximum X value of query envelope’) / 2 "
"The value of parameter Z is ‘foo’ "

This is done via the classes in my tree of gt-wfs-ng, package org.geotools.data.wfs.internal.v2_0.storedquery. These classes are persisted in featuretype.xml and the configuration is set up in the UI, so the classes must be available (somehow) for the UI to work. As the classes are in gt-wfs-ng, the requirement that geoserver work with either gt-wfs or gt-wfs-ng plugged in, is a big problem.

Does this help or are we talking about different things?

Sampo

On Mon, Jun 23, 2014 at 9:47 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Let me check…

Factory is used in:

  • RemoteOWSTestSupport: Just a test so it can have a direct dependency. Checking the details the factory is used both directly and for the parameter keys. No reason not to inline the keys and use datastore finder

  • GetMapKvpRequestReader: same deal, used for parameter keys and could be replaced

WFSDataStore interface: not used directly in GeoServer
WFS_1_0_0_DataStore: not used directly in GeoServer

WFS_1_1_0_DataStore: not used directly in GeoServer

WFSTransactionState: not used directly by GeoServer

So perhaps you can be more specific?

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 3:51 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

By “constants”, were you referring to the parameter classes? The classes I’m talking about are proper real live classes which are used to configure how stored query parameters are derived from the query. These are much more complex than constants.

Sampo

On Mon, Jun 23, 2014 at 12:28 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We do not have that many references to these constants, consider using “inline” with a TODO comment to switch it back after the migration is complete. Has the advantage of being easy/quick.

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

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

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.

15

Hi,

On a related note. I’m slightly confused to how current master of gt + gs should work. I’m trying to get wfs-ng working (“activated”), but I’m not getting much traction. Master (pure, not my branch) with the old wfs module seems to work fine, but If I switch the modules (remove gt-wfs, add gt-wfs-ng), server startup will fail:

23 Jun 12:51:12 WARN [support.DisposableBeanAdapter] - Invocation of destroy method failed on bean with name ‘geoServerLoader’: org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name ‘GWCLifeCycleHandler’: 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!)
23 Jun 12:51:12 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘wfsDataStorePanel’ defined in URL [jar:file:/home/savolais/twosix/geoserver-2.6-SNAPSHOT/webapps/geoserver/WEB-INF/lib/gs-web-core-2.6-SNAPSHOT.jar!/applicationContext.xml]: Initialization of bean failed; nested exception is org.springframework.beans.TypeMismatchException: Failed to convert property value of type ‘java.lang.String’ to required type ‘java.lang.Class’ for property ‘factoryClass’; nested exception is java.lang.IllegalArgumentException: Cannot find class [org.geotools.data.wfs.WFSDataStoreFactory]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)

Is current master broken or am I missing something?

S.

···

On Mon, Jun 23, 2014 at 11:42 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi Jody,

Yes, we’ve managed to talk about different things. The parameters I’m talking about are not parameters for the data store, but configuration classes that dictate how cascaded stored queries are executed. For every layer based on cascaded stored queries, there is configuration relatively similar to SQL views. In this case, the configure defines what Stored Query Parameters are sent via each cascaded request. This method can be used to define both static and dynamic values for the parameters (via CQL expressions).

The parameters are stored in featuretype.xml as layer metadata and are passed on as query hints (as with SQL views). The data store then reads these hints and uses them, the query and user supplied viewparams to construct the parameters sent with the stored query request.

Like I mentioned earlier, the classes are needed in geoserver so the UI may manipulate these objects (and serialize/deserialize objects from the data directory).

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 Mon, Jun 23, 2014 at 10:15 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We may be talking about different things, I am talking about datastore connection parameter constants defined in WFSDataStoreFactory. They are explicitly referenced via an import statement in a couple GeoServer files. For the current use of WFSDataStore we would be able to inline these values.

It sounds like a dependency to wfs-ng is needed for your branch. Are your parameters part of DataStore construction or are they additional Query parameters?

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 4:59 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

The configuration for a cascaded stored query specifies how the parameters for a cascaded request are mapped from viewparams (as SQL views), defaults, and the context of the original query (query envelope, for example).

So a layer created from a cascaded stored query might define:
"The value of parameter X is defined as (‘minimum X value of query envelope’ + ‘maximum X value of query envelope’) / 2 "
"The value of parameter Z is ‘foo’ "

This is done via the classes in my tree of gt-wfs-ng, package org.geotools.data.wfs.internal.v2_0.storedquery. These classes are persisted in featuretype.xml and the configuration is set up in the UI, so the classes must be available (somehow) for the UI to work. As the classes are in gt-wfs-ng, the requirement that geoserver work with either gt-wfs or gt-wfs-ng plugged in, is a big problem.

Does this help or are we talking about different things?

Sampo

On Mon, Jun 23, 2014 at 9:47 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Let me check…

Factory is used in:

  • RemoteOWSTestSupport: Just a test so it can have a direct dependency. Checking the details the factory is used both directly and for the parameter keys. No reason not to inline the keys and use datastore finder

  • GetMapKvpRequestReader: same deal, used for parameter keys and could be replaced

WFSDataStore interface: not used directly in GeoServer
WFS_1_0_0_DataStore: not used directly in GeoServer

WFS_1_1_0_DataStore: not used directly in GeoServer

WFSTransactionState: not used directly by GeoServer

So perhaps you can be more specific?

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 3:51 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

By “constants”, were you referring to the parameter classes? The classes I’m talking about are proper real live classes which are used to configure how stored query parameters are derived from the query. These are much more complex than constants.

Sampo

On Mon, Jun 23, 2014 at 12:28 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We do not have that many references to these constants, consider using “inline” with a TODO comment to switch it back after the migration is complete. Has the advantage of being easy/quick.

–

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.

Jody Garnett

On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Good point. We can compile my current branch as-is if we depend on gt-wfs-ng as a provided dependency, but that won’t stop things from breaking at runtime. The classes that are used to define the values of stored query parameters currently reside in gt-wfs-ng, so this would need to be refactored for the drop-in replacement idea to work in my case.

Just to throw out some ideas:

  1. The parameter classes could be moved to geoserver so they would be available regardless if the user uses wfs or wfs-ng. This would however place the burden of resolving the parameters into gs instead of gt-wfs-ng and would reduce the usefulness of the stored query support in standalone gt (i.e. without geoserver)
  2. The parameter classes could be moved somewhere closer to gt core so they would be available regardless if wfs or wfs-ng is plugged in.
  3. UI code relating to the stored query configuration can be wrapped with reflection and Class.forName() and protected so it will work regardless wfs or wfs-ng is in use

Option 1 is less than optimal design wise as it would lessen the usefulness of cascaded stored query sources. Option 3 would require a lot of tip-toeing around and we would end up with somewhat dirty code. This is especially unfortunate as this affects a core UI view. Option 2 feels best from my view.

Thoughts? If you feel option 2 is the way to go, I’d appreciate ideas regarding where the parameter classes should be stored in.

Sampo

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

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

On Wed, Jun 18, 2014 at 11:36 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 Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No objection personally, but I’m wondering how that will affect Sampo’s work.
I supposedhis pull request won’t even compile if we are not depending on wfs-ng?
https://github.com/geoserver/geoserver/pull/611

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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

Cool, I think for now what I’ll do is proceed with making wfs-ng a pure drop in and package it up as a community module for geoserver. Along with it documentation that specifies installing it requires removing the old one**. And then once we are more confident with it and it has seen some more user testing we can perhaps perform the switch and make it the default, packaging up the original as an extension.