[Geoserver-devel] handling lookups with un-prefixed names

GeoServer GeoServer Developer
1

Hi all,

I just committed a change to the Data class which handles lookups for feature info objects with un-prefixed names. The basic logic is that if there is only name that matches, that will be the one returned. I also had to add some logic around the layer type lookup since if an un-prefixed name is handled with a direct feature type info lookup, it should be handled when a layer type lookup is done with the same name.

It is not a huge change but nontheless it is a commit to core code so I would like a review. The commit is revision 8593. I can back the change out easily if there are issues.

-Justin

2

Justin Deoliveira ha scritto:

Hi all,

I just committed a change to the Data class which handles lookups for feature info objects with un-prefixed names. The basic logic is that if there is only name that matches, that will be the one returned. I also had to add some logic around the layer type lookup since if an un-prefixed name is handled with a direct feature type info lookup, it should be handled when a layer type lookup is done with the same name.

It is not a huge change but nontheless it is a commit to core code so I would like a review. The commit is revision 8593. I can back the change out easily if there are issues.

Hum, I had a look at the patch and it seems ok code wise. The usual steps are followed anyways:
* try a full match
* try adding the default namespace prefix in front of the name

and then the full match by name is tried. Yet, I'm not sure I
understand why we need to match the unprefixed names out of the
default namespace... that is, we never had this behaviour.

It this patch related to http://jira.codehaus.org/browse/GEOS-1816?
In that case the layer name was states, so prefixing it with
the default namespace should have done the trick?

I'm just trying to understand what's the use case for this.
Think of the consequences. You have a certain feature type "XX"
in a non default namespace, you make an unprefixed request,
you get back data. Then you add another "XX" in a different namespace
and boom, the previous request stops working because now you have two
(the patch returns a feature type only if it can find one instance).
Or you add a new "XX" to the default namespace, and you start getting
back completely different data (since the one in the default namespace
is looked up before the unprefixed match attempt).

Yet, you can get a similar mess with the old code as well, you just have to change the default namespace and all your unprefixed queries go bye bye. Yet it seems to me the patch might increase this confusing behaviour.

Opinions?
Cheers
Andrea

3

Let me state my rationale, should have in the first email. I think that as GeoServer moves toward restful services, the need to reference layers or resources without a namespace prefix is going to increase. And we will see layers showing up in url's. Like for geosync:

http://geoserver…/history/states/changes

Having to do:

http://geoserver…/history/topp:states/changes

is a bit strange. I know in this case states in usually in the default namespace but that is really besides the point.

Also, with the new config model we have a chance to make namespaces less prevalent. I see them as being something that should only apply to WFS. Having the notion of a namespace in WMS is something that people continually have trouble with. The result has been us developing things like "wmsPath", which is kind of a band aid solution in my opinion.

Anyways... the point is that I think we are going to have to deal with this at sometime. Regardless, you bring up a good point Andrea, about confusing results with multiple layers in different namespaces. I think in the least we should add a meaningful exception for the case when there are multiple, and that user has not used a prefix.

My 2c. I am eager to hear others thoughts on this.

-Justin

Hum, I had a look at the patch and it seems ok code wise. The usual steps are followed anyways:
* try a full match
* try adding the default namespace prefix in front of the name

and then the full match by name is tried. Yet, I'm not sure I
understand why we need to match the unprefixed names out of the
default namespace... that is, we never had this behaviour.

It this patch related to http://jira.codehaus.org/browse/GEOS-1816?
In that case the layer name was states, so prefixing it with
the default namespace should have done the trick?

I'm just trying to understand what's the use case for this.
Think of the consequences. You have a certain feature type "XX"
in a non default namespace, you make an unprefixed request,
you get back data. Then you add another "XX" in a different namespace
and boom, the previous request stops working because now you have two
(the patch returns a feature type only if it can find one instance).
Or you add a new "XX" to the default namespace, and you start getting
back completely different data (since the one in the default namespace
is looked up before the unprefixed match attempt).

Yet, you can get a similar mess with the old code as well, you just have to change the default namespace and all your unprefixed queries go bye bye. Yet it seems to me the patch might increase this confusing behaviour.

Opinions?
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,47e0d98f299621431913854!

4

I actually think namespaces are a very cool idea in geoserver. They
allow a common back-end data "structuring" that allows different blocks
of data to have the same type name without conflicting.

Also, the wmsPath (as I understand it) doesn't really have much to do
with namespaces. It's about mapping wms layers into the (imho confused)
wms layer "tree". Am I confusing that wmsPath with a a different one
(the one on the UI?)

Either way, I'm definitely +1 for keeping namespaces around!

--saul

On Wed, 2008-03-19 at 10:11 -0700, Justin Deoliveira wrote:

Let me state my rationale, should have in the first email. I think that
as GeoServer moves toward restful services, the need to reference layers
or resources without a namespace prefix is going to increase. And we
will see layers showing up in url's. Like for geosync:

http://geoserver…/history/states/changes

Having to do:

http://geoserver…/history/topp:states/changes

is a bit strange. I know in this case states in usually in the default
namespace but that is really besides the point.

Also, with the new config model we have a chance to make namespaces less
prevalent. I see them as being something that should only apply to WFS.
Having the notion of a namespace in WMS is something that people
continually have trouble with. The result has been us developing things
like "wmsPath", which is kind of a band aid solution in my opinion.

Anyways... the point is that I think we are going to have to deal with
this at sometime. Regardless, you bring up a good point Andrea, about
confusing results with multiple layers in different namespaces. I think
in the least we should add a meaningful exception for the case when
there are multiple, and that user has not used a prefix.

My 2c. I am eager to hear others thoughts on this.

-Justin

>
> Hum, I had a look at the patch and it seems ok code wise. The usual
> steps are followed anyways:
> * try a full match
> * try adding the default namespace prefix in front of the name
>
> and then the full match by name is tried. Yet, I'm not sure I
> understand why we need to match the unprefixed names out of the
> default namespace... that is, we never had this behaviour.
>
> It this patch related to http://jira.codehaus.org/browse/GEOS-1816?
> In that case the layer name was states, so prefixing it with
> the default namespace should have done the trick?
>
> I'm just trying to understand what's the use case for this.
> Think of the consequences. You have a certain feature type "XX"
> in a non default namespace, you make an unprefixed request,
> you get back data. Then you add another "XX" in a different namespace
> and boom, the previous request stops working because now you have two
> (the patch returns a feature type only if it can find one instance).
> Or you add a new "XX" to the default namespace, and you start getting
> back completely different data (since the one in the default namespace
> is looked up before the unprefixed match attempt).
>
> Yet, you can get a similar mess with the old code as well, you just have
> to change the default namespace and all your unprefixed queries go bye
> bye. Yet it seems to me the patch might increase this confusing behaviour.
>
> Opinions?
> Cheers
> Andrea
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:4007,47e0d98f299621431913854!
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Saul Farber ha scritto:

I actually think namespaces are a very cool idea in geoserver. They
allow a common back-end data "structuring" that allows different blocks
of data to have the same type name without conflicting.

Also, the wmsPath (as I understand it) doesn't really have much to do
with namespaces. It's about mapping wms layers into the (imho confused)
wms layer "tree". Am I confusing that wmsPath with a a different one
(the one on the UI?)

Either way, I'm definitely +1 for keeping namespaces around!

I'm definitely +1 me too, since they are a nice way to organise thing,
and we're going to use them to tie down security as well.

Anyways, Justin's patch is more about not enforcing their usage.
I guess that with the appropriate error message, like:
"Hey moron, there are mgis:states, sf:states, cite:states, care
to tell me which one you want?"

allowing a non prefixed match by full scan all existing layers is
going to be fine.

Cheers
Andrea