[Geoserver-devel] round 2 of virtual services

GeoServer GeoServer Developer
1

Hi all,

Recently I have started some spare time hacking with the goal of completing the virtual services stuff. As many know the current implementation is incomplete at this point. It let’s you partition up layers by workspace and provides service endpoints for just those layers, but that is about it. Major things missing in my mind include:

  1. Per workspace service configuration
  2. Per workspace layer groups
  3. Per workspace styles

1 is pretty clear in my mind, to truly have virtual services we need to configure those services independent of one another, rather than just having one global service. Initially I thought 2 and 3 were pretty clear cut but the more I think about it i am not so sure.

Let’s take layer groups. Currently the way things work with regard to virtual services is that a layer group is included in a virtual wms endpoint if all the layers in that group are also included in that endpoint. So if you say have a layer group that contains layers across multiple workspaces then it will never be accessible through a virtual service endpoint. And the question I go back and forth on is if that current behaviour is good enough.

I can think of cases where it would be nice to explicitly associate a layer group with a workspace. One would be the case i mentioned above in which we have a layer group that is backed by layers from multiple workspaces and we want that layer group to be accessible from one of the virtual workspace wms endpoints. Another case (well actually it is the same case) is to create a workspace that just consists of layer groups that we want to publish, while the layers are actually in another workspace. A way to achieve the “non declared” layer functionality that was discussed a few weeks back.

Anyways, not sure if that is clear or not, but I thought I would write an email to try and gather thoughts from people and perhaps build a stronger case either way. I actually have the same question for styles… does it make sense to group them by workspace. From a virtual services perspective probably not so much but from an organizational perspective it could be a nice thing to have. Same argument for layer groups.

Thoughts and opinions much appreciated.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

Hello Justin,

just a quick thought about the styles use-case … what about if I would reuse a style on layers spread on different workspaces? I don’t want to duplicate my style for each workspace.

Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
http://twitter.com/geosolutions_it

On Tue, Sep 20, 2011 at 10:03 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

Recently I have started some spare time hacking with the goal of completing the virtual services stuff. As many know the current implementation is incomplete at this point. It let’s you partition up layers by workspace and provides service endpoints for just those layers, but that is about it. Major things missing in my mind include:

  1. Per workspace service configuration
  2. Per workspace layer groups
  3. Per workspace styles

1 is pretty clear in my mind, to truly have virtual services we need to configure those services independent of one another, rather than just having one global service. Initially I thought 2 and 3 were pretty clear cut but the more I think about it i am not so sure.

Let’s take layer groups. Currently the way things work with regard to virtual services is that a layer group is included in a virtual wms endpoint if all the layers in that group are also included in that endpoint. So if you say have a layer group that contains layers across multiple workspaces then it will never be accessible through a virtual service endpoint. And the question I go back and forth on is if that current behaviour is good enough.

I can think of cases where it would be nice to explicitly associate a layer group with a workspace. One would be the case i mentioned above in which we have a layer group that is backed by layers from multiple workspaces and we want that layer group to be accessible from one of the virtual workspace wms endpoints. Another case (well actually it is the same case) is to create a workspace that just consists of layer groups that we want to publish, while the layers are actually in another workspace. A way to achieve the “non declared” layer functionality that was discussed a few weeks back.

Anyways, not sure if that is clear or not, but I thought I would write an email to try and gather thoughts from people and perhaps build a stronger case either way. I actually have the same question for styles… does it make sense to group them by workspace. From a virtual services perspective probably not so much but from an organizational perspective it could be a nice thing to have. Same argument for layer groups.

Thoughts and opinions much appreciated.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1

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

3

Hey Alessio, yeah that is a good point. My thought was to have both “global” and “workspace local” styles. Basically giving you the best of both worlds.

On Wed, Sep 21, 2011 at 4:23 PM, Alessio Fabiani <alessio.fabiani@anonymised.com> wrote:

Hello Justin,

just a quick thought about the styles use-case … what about if I would reuse a style on layers spread on different workspaces? I don’t want to duplicate my style for each workspace.

Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com

http://www.linkedin.com/in/alessiofabiani
http://twitter.com/geosolutions_it

On Tue, Sep 20, 2011 at 10:03 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

Recently I have started some spare time hacking with the goal of completing the virtual services stuff. As many know the current implementation is incomplete at this point. It let’s you partition up layers by workspace and provides service endpoints for just those layers, but that is about it. Major things missing in my mind include:

  1. Per workspace service configuration
  2. Per workspace layer groups
  3. Per workspace styles

1 is pretty clear in my mind, to truly have virtual services we need to configure those services independent of one another, rather than just having one global service. Initially I thought 2 and 3 were pretty clear cut but the more I think about it i am not so sure.

Let’s take layer groups. Currently the way things work with regard to virtual services is that a layer group is included in a virtual wms endpoint if all the layers in that group are also included in that endpoint. So if you say have a layer group that contains layers across multiple workspaces then it will never be accessible through a virtual service endpoint. And the question I go back and forth on is if that current behaviour is good enough.

I can think of cases where it would be nice to explicitly associate a layer group with a workspace. One would be the case i mentioned above in which we have a layer group that is backed by layers from multiple workspaces and we want that layer group to be accessible from one of the virtual workspace wms endpoints. Another case (well actually it is the same case) is to create a workspace that just consists of layer groups that we want to publish, while the layers are actually in another workspace. A way to achieve the “non declared” layer functionality that was discussed a few weeks back.

Anyways, not sure if that is clear or not, but I thought I would write an email to try and gather thoughts from people and perhaps build a stronger case either way. I actually have the same question for styles… does it make sense to group them by workspace. From a virtual services perspective probably not so much but from an organizational perspective it could be a nice thing to have. Same argument for layer groups.

Thoughts and opinions much appreciated.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1

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

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

On Wed, Sep 21, 2011 at 6:03 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
Recently I have started some spare time hacking with the goal of completing
the virtual services stuff. As many know the current implementation is
incomplete at this point. It let's you partition up layers by workspace and
provides service endpoints for just those layers, but that is about it.
Major things missing in my mind include:
1. Per workspace service configuration

+1

2. Per workspace layer groups

Yep, a bit problematic

3. Per workspace styles

+1

1 is pretty clear in my mind, to truly have virtual services we need to
configure those services independent of one another, rather than just having
one global service. Initially I thought 2 and 3 were pretty clear cut but
the more I think about it i am not so sure.
Let's take layer groups. Currently the way things work with regard to
virtual services is that a layer group is included in a virtual wms endpoint
if all the layers in that group are also included in that endpoint. So if
you say have a layer group that contains layers across multiple workspaces
then it will never be accessible through a virtual service endpoint. And the
question I go back and forth on is if that current behaviour is good
enough.
I can think of cases where it would be nice to explicitly associate a layer
group with a workspace. One would be the case i mentioned above in which we
have a layer group that is backed by layers from multiple workspaces and we
want that layer group to be accessible from one of the virtual workspace wms
endpoints. Another case (well actually it is the same case) is to create a
workspace that just consists of layer groups that we want to publish, while
the layers are actually in another workspace. A way to achieve the "non
declared" layer functionality that was discussed a few weeks back.

I don't have a problem in principle, but this might be problematic
because of the
way layer groups are implemented.
You reach into a specific workspace, the layer group is found in the kvp request
parsers exploded in the layers composing it, however the catalog should
refuse to give you those layers outside of the current workspace (this
is actually
what makes the current "per workspace" service work right now).

If we go there and allow a layer group to pick stuff cross workspace we should
allow picking up from other workspaces, but only if the reference comes though
a layer group. I fear this might get quite hairy.

Ideas:
- make a workspace be the default or the global, the one that everybody can
  pick from, and allow cross workspace access to just that one
- allow a local layer to be just a "symlink" to another layer in
another workspace...
  though this might cause issues in a multi-tenancy setup (one admin of
  one workspace symlinks another layer and bypasses its security settings...
  more on multitenancy later).

Anyways, not sure if that is clear or not, but I thought I would write an
email to try and gather thoughts from people and perhaps build a stronger
case either way. I actually have the same question for styles... does it
make sense to group them by workspace. From a virtual services perspective
probably not so much but from an organizational perspective it could be a
nice thing to have. Same argument for layer groups.

Yeah, having everything specified per workspace would make it possible to
have per workspace administration rights, which now make little/no sense
due to the shared parts. It would require quite a bit of work to implement, but
at least we'd have the basis for that work to make sense.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

5

I like workspaces going more configuration containers and less
namespace siblings. Which inevitably brings me up to one thing that
concerns me more: I think in order to do all this well we'll also need
to break the 1-1 relationship between workspace and namespace. Thing
is more datastore types that provide feature types in more than one
namespace are to come, besides wfs datastore, which is btw about to
get a revamp thanks to GeoNode needs.

So I'm not so sure if we need per workspace namespaces, guess not.
They're after all just a means to assign a namespace to types from
datastores that doesn't provide namespace scoped feature types. But I
think we certainly need to break that relation (ws<-->ns) sooner
rather than later.

Now, in order to get to your actual question:

Major things missing in my mind include:
1. Per workspace service configuration

+1

2. Per workspace layer groups

+1

3. Per workspace styles

+1

I see how a virtual service at /geoserver/ws1 differs from another
/geoserver/ws2 as they map to different workspaces. Just don't see why
all feature types on each of them should belong to a single namespace.
Ultimately, namsepace is just something relevant to the WFS interface,
and I realize what I'm talking about is more like the eternal
resource/publish split. But if you really want the freedom of creating
virtual services backed by workspaces, you'll want feature types in a
single workspace to come from different workspaces, rest aside the
case of datastore providing types in multiple namespaces "natively".

2c./

Gabriel

6

On Fri, Sep 23, 2011 at 10:36 PM, Gabriel Roldan <groldan@anonymised.com1…> wrote:

I like workspaces going more configuration containers and less
namespace siblings. Which inevitably brings me up to one thing that
concerns me more: I think in order to do all this well we’ll also need
to break the 1-1 relationship between workspace and namespace.

I agree on the concern. I am also worried about this one too, mostly because
Justin said this is on his spare time: if we just go and ask too much we’ll
end up getting nothing.

Thing
is more datastore types that provide feature types in more than one
namespace are to come, besides wfs datastore, which is btw about to
get a revamp thanks to GeoNode needs.

Now this is interesting, I was half considering trying a rewrite in my spare
time based on content data store (then decided to go for a OGR store
rewrite, more on this in the next days).
Are you going to base it on the content data store? The issue I saw there
is that content ds does not handle complex data, one would need a
base class “ComplexContentDataAccess” or something like that.

The other issue I saw is that one need to delve deep down in the
wfs bindings to make them able to parse, not just encode, the
WFS 1.0 and 1.1 protocols

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

7

On Sat, Sep 24, 2011 at 3:42 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Fri, Sep 23, 2011 at 10:36 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

I like workspaces going more configuration containers and less
namespace siblings. Which inevitably brings me up to one thing that
concerns me more: I think in order to do all this well we'll also need
to break the 1-1 relationship between workspace and namespace.

I agree on the concern. I am also worried about this one too, mostly because
Justin said this is on his spare time: if we just go and ask too much we'll
end up getting nothing.

yeah I should have mentioned I am sensitive to this and thankful he's
using his spare time for it, hence not requiring to take care of this
but just felt it was a concern that needed to be raised, paired with
the will to help out.

Thing
is more datastore types that provide feature types in more than one
namespace are to come, besides wfs datastore, which is btw about to
get a revamp thanks to GeoNode needs.

Now this is interesting, I was half considering trying a rewrite in my spare
time based on content data store (then decided to go for a OGR store
rewrite, more on this in the next days).
Are you going to base it on the content data store? The issue I saw there
is that content ds does not handle complex data, one would need a
base class "ComplexContentDataAccess" or something like that.
The other issue I saw is that one need to delve deep down in the
wfs bindings to make them able to parse, not just encode, the
WFS 1.0 and 1.1 protocols

Well, hopefully we'll get enough time to work on it as to do it well.
What will that encompass I'm not totally sure right now. My experience
when worked on the wfs 1.1 datastore a couple years back was that the
gt-xsd framework was too heavy and the streaming parser was too
difficult for me to fix (it OOM'ed) that it was easier to come up with
a simple StAX streaming parser.
So we either go that route or get the gt-xsd streaming parser in
shape. Hopefully the design allows for parser pluggability already and
there's actually a gt-xsd one, it's just not being used.

wrt ContentDataStore superclass or not, again, something to be
assessed when the time comes.

Cheers,
Gabriel

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

8

Hey guys,

On Sat, Sep 24, 2011 at 11:33 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

On Sat, Sep 24, 2011 at 3:42 AM, Andrea Aime

<andrea.aime@anonymised.com> wrote:

On Fri, Sep 23, 2011 at 10:36 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:

I like workspaces going more configuration containers and less
namespace siblings. Which inevitably brings me up to one thing that
concerns me more: I think in order to do all this well we’ll also need
to break the 1-1 relationship between workspace and namespace.

I agree on the concern. I am also worried about this one too, mostly because
Justin said this is on his spare time: if we just go and ask too much we’ll
end up getting nothing.

yeah I should have mentioned I am sensitive to this and thankful he’s
using his spare time for it, hence not requiring to take care of this
but just felt it was a concern that needed to be raised, paired with
the will to help out.

Well I definitely find the dialogue very useful so I definitely don’t mind some scope increase in terms of discussion. In the end though I do think the two bits of work are somewhat separate, or in the least can be done incrementally. The question that I have is once we do break 1-1 workspace/namespace what will the relationship be? Should we allow namespaces to be constrained to a workspace? Or should they sit parallel to them in the configuration model and be global? I can’t think of a great use case for having namespaces be local to a workspace…

Thing
is more datastore types that provide feature types in more than one
namespace are to come, besides wfs datastore, which is btw about to
get a revamp thanks to GeoNode needs.

Now this is interesting, I was half considering trying a rewrite in my spare
time based on content data store (then decided to go for a OGR store
rewrite, more on this in the next days).
Are you going to base it on the content data store? The issue I saw there
is that content ds does not handle complex data, one would need a
base class “ComplexContentDataAccess” or something like that.
The other issue I saw is that one need to delve deep down in the
wfs bindings to make them able to parse, not just encode, the
WFS 1.0 and 1.1 protocols

Well, hopefully we’ll get enough time to work on it as to do it well.
What will that encompass I’m not totally sure right now. My experience
when worked on the wfs 1.1 datastore a couple years back was that the
gt-xsd framework was too heavy and the streaming parser was too
difficult for me to fix (it OOM’ed) that it was easier to come up with
a simple StAX streaming parser.
So we either go that route or get the gt-xsd streaming parser in
shape. Hopefully the design allows for parser pluggability already and
there’s actually a gt-xsd one, it’s just not being used.

wrt ContentDataStore superclass or not, again, something to be
assessed when the time comes.

Cheers,
Gabriel

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

9

On Mon, Sep 26, 2011 at 10:56 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Well I definitely find the dialogue very useful so I definitely don't mind
some scope increase in terms of discussion. In the end though I do think the
two bits of work are somewhat separate, or in the least can be done
incrementally. The question that I have is once we do break 1-1
workspace/namespace what will the relationship be? Should we allow
namespaces to be constrained to a workspace? Or should they sit parallel to
them in the configuration model and be global? I can't think of a great use
case for having namespaces be local to a workspace...

Neither do I, and I would prefer them being global too. Although we
should ask whether it'd have an impact on the complex-feature land.
I'm pretty sure it won't, cause we're defining _just_ the namespace,
not the schemaLocations, so we should be good.
Rationale is that complex-feature people use(d) to publish two feature
types on the same namespace but for different versions of it (given by
the schemaLocation).
So I'm pretty sure this is mostly random ranting, but just to make
sure I'd like to hear from them?

All in all, it will be nice to have feature types constrained to a
workspace as a "container" but being able to pick a DataStore
namespace (as it's no more than a DataStore parameter) from the global
list of namespaces.

2c/

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

10

On Mon, Sep 26, 2011 at 3:56 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Well I definitely find the dialogue very useful so I definitely don't mind
some scope increase in terms of discussion. In the end though I do think the
two bits of work are somewhat separate, or in the least can be done
incrementally. The question that I have is once we do break 1-1
workspace/namespace what will the relationship be? Should we allow
namespaces to be constrained to a workspace? Or should they sit parallel to
them in the configuration model and be global? I can't think of a great use
case for having namespaces be local to a workspace...

The only issue I can think of is uniqueness.
Nowadays you have to make sure the store and feature type are unique per
workspace, having a free namespace choice makes things a little more
complicated,
like, the code will have to perform more checks and eventually return
an error like
"abc:type is already registered in workspace xyz" or something like that.

Also, it might be useful to still have a default namespace attached to
the workspace,
so that people don't have to choose it every time (being able to choose whatever
you want is nice, being forced to choose every time might be annoying).

Of course with stores free to setup their own namespace we won't have guarantees
that there are no conflicts, maybe the store config changes and boom we get with
a duplicate.

Now this is sort of interesting for the WFS cascading case. I see that the WFS
store does not accept a namespace param today, and this is going to cause issues
imho: if I'm cascading I should be able to force down the WFS store throat a
different namespace, just like I can choose a different layer name, but that
does not seem to be working today, and actually, you cannot do wfs 1.1
on a cascaded wfs 1.0 store because there are no namespaces at all (and the
wfs 1.1 encoding code assumes there will always be one instead)

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

11

On Wed, Sep 28, 2011 at 3:54 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Sep 26, 2011 at 3:56 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Well I definitely find the dialogue very useful so I definitely don't mind
some scope increase in terms of discussion. In the end though I do think the
two bits of work are somewhat separate, or in the least can be done
incrementally. The question that I have is once we do break 1-1
workspace/namespace what will the relationship be? Should we allow
namespaces to be constrained to a workspace? Or should they sit parallel to
them in the configuration model and be global? I can't think of a great use
case for having namespaces be local to a workspace...

The only issue I can think of is uniqueness.
Nowadays you have to make sure the store and feature type are unique per
workspace, having a free namespace choice makes things a little more
complicated,
like, the code will have to perform more checks and eventually return
an error like
"abc:type is already registered in workspace xyz" or something like that.

Also, it might be useful to still have a default namespace attached to
the workspace,
so that people don't have to choose it every time (being able to choose whatever
you want is nice, being forced to choose every time might be annoying).

Of course with stores free to setup their own namespace we won't have guarantees
that there are no conflicts, maybe the store config changes and boom we get with
a duplicate.

Now this is sort of interesting for the WFS cascading case. I see that the WFS
store does not accept a namespace param today, and this is going to cause issues
imho: if I'm cascading I should be able to force down the WFS store throat a
different namespace, just like I can choose a different layer name, but that
does not seem to be working today, and actually, you cannot do wfs 1.1
on a cascaded wfs 1.0 store because there are no namespaces at all (and the
wfs 1.1 encoding code assumes there will always be one instead)

well, that is something I was casually working on just today, as I'm
sort of starting to make sure the cascaded wfs behaves (and it worked
for wms but didn't for wfs requests just because of that reason).
so the idea is that you provide a namespace parameter and it overrides
the namespace for all the cascaded types, that become
<overrideprefix>:<originalprefix_originalSimpleName>

Cheers
Andrea

--

12

On Wed, Sep 28, 2011 at 7:11 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Now this is sort of interesting for the WFS cascading case. I see that the WFS
store does not accept a namespace param today, and this is going to cause issues
imho: if I'm cascading I should be able to force down the WFS store throat a
different namespace, just like I can choose a different layer name, but that
does not seem to be working today, and actually, you cannot do wfs 1.1
on a cascaded wfs 1.0 store because there are no namespaces at all (and the
wfs 1.1 encoding code assumes there will always be one instead)

well, that is something I was casually working on just today, as I'm
sort of starting to make sure the cascaded wfs behaves (and it worked
for wms but didn't for wfs requests just because of that reason).
so the idea is that you provide a namespace parameter and it overrides
the namespace for all the cascaded types, that become
<overrideprefix>:<originalprefix_originalSimpleName>

By the other side, ContentDataStore explicitly mentions:

* Each entry is identified by a name ({@link Name}). The name can be qualified
* with a namespace uri, or unqualified (in which the namespace uri is
null). An
* example of a datastore that might use qualified names is WFS, where in each
* entry corresponds to a WFS "Feature Type", which have namespace
qualified name.
* Other datastores (such as databases) use unqualified names.

But I doubt it has ever been tested with an implementation that
provides feature types in different namespaces already?

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.