[Geoserver-devel] workspace not honored in admin layer configuration page

When setting up multiple layers with the same name but different
workspaces, the admin ui doesn't use the workspace to correctly
distinguish them. In other words, if I set up 2 layers with the same
name but with different workspaces, clicking on them to get to the
layer configuration page navigates to the same layer in both cases.

I dug into this a little bit, and the catalog implementation that gets
used is the LocalWorkspaceCatalog. There's no thread local workspace
set when I trace through the code path, but it strips off the
workspace part of it when trying to find the layer. Here's the
relevant code:

    @Override
    public LayerInfo getLayerByName(String name) {
        if (LocalWorkspace.get() != null) {
            String wsName = LocalWorkspace.get().getName();

            //prefix the unqualified name
            if (name.contains(":")) {
                //name already prefixed, ensure it is prefixed with
the correct one
                if (name.startsWith(wsName+":")) {
                    //good to go, just pass call through
                    return wrap(super.getLayerByName(name));
                }
                else {
                    //JD: perhaps strip of existing prefix?
                }
            }

            //prefix it explicitly
            NamespaceInfo ns =
super.getNamespaceByPrefix(LocalWorkspace.get().getName());
            LayerInfo layer = super.getLayerByName(new
NameImpl(ns.getURI(), name));
            return wrap(layer);
        }
        return super.getLayerByName(name);
    }

    @Override
    public LayerInfo getLayerByName(Name name) {
        return getLayerByName(name.getLocalPart());
    }

The getLayerByName(Name) method is the one that gets called, and the
workspace part of the query is lost when it delegates to the
getLayerByName(String) method. If I instead only delegate when there
is a thread local workspace, it works for me.

    public LayerInfo getLayerByName(Name name) {
        if (LocalWorkspace.get() != null) {
            return getLayerByName(name.getLocalPart());
        } else {
            return super.getLayerByName(name);
        }
    }

If this is the right approach, I can submit a jira issue, and attach a
patch with a test.

Robert

Hey Rob,

Your fix makes sense and I think is the right approach. If you could attach your patch to a jira ticket that would be great. If you could also run all of the unit tests with your patch applied to ensure that doesn’t lead to any other issues that would be great as well.

Thanks!

-Justin

On Mon, Jul 2, 2012 at 12:12 PM, Rob Marianski <rmarianski@anonymised.com.> wrote:

When setting up multiple layers with the same name but different
workspaces, the admin ui doesn’t use the workspace to correctly
distinguish them. In other words, if I set up 2 layers with the same
name but with different workspaces, clicking on them to get to the
layer configuration page navigates to the same layer in both cases.

I dug into this a little bit, and the catalog implementation that gets
used is the LocalWorkspaceCatalog. There’s no thread local workspace
set when I trace through the code path, but it strips off the
workspace part of it when trying to find the layer. Here’s the
relevant code:

@Override
public LayerInfo getLayerByName(String name) {
if (LocalWorkspace.get() != null) {
String wsName = LocalWorkspace.get().getName();

//prefix the unqualified name
if (name.contains(“:”)) {
//name already prefixed, ensure it is prefixed with
the correct one
if (name.startsWith(wsName+“:”)) {
//good to go, just pass call through
return wrap(super.getLayerByName(name));
}
else {
//JD: perhaps strip of existing prefix?
}
}

//prefix it explicitly
NamespaceInfo ns =
super.getNamespaceByPrefix(LocalWorkspace.get().getName());
LayerInfo layer = super.getLayerByName(new
NameImpl(ns.getURI(), name));
return wrap(layer);
}
return super.getLayerByName(name);
}

@Override
public LayerInfo getLayerByName(Name name) {
return getLayerByName(name.getLocalPart());
}

The getLayerByName(Name) method is the one that gets called, and the
workspace part of the query is lost when it delegates to the
getLayerByName(String) method. If I instead only delegate when there
is a thread local workspace, it works for me.

public LayerInfo getLayerByName(Name name) {
if (LocalWorkspace.get() != null) {
return getLayerByName(name.getLocalPart());
} else {
return super.getLayerByName(name);
}
}

If this is the right approach, I can submit a jira issue, and attach a
patch with a test.

Robert


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


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

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

All unit tests passed for me afterwards. Shout out to Dwins for his help here.

Robert

On Mon, Jul 2, 2012 at 3:32 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hey Rob,

Your fix makes sense and I think is the right approach. If you could attach
your patch to a jira ticket that would be great. If you could also run all
of the unit tests with your patch applied to ensure that doesn't lead to any
other issues that would be great as well.

Thanks!

-Justin

On Mon, Jul 2, 2012 at 12:12 PM, Rob Marianski <rmarianski@anonymised.com>
wrote:

When setting up multiple layers with the same name but different
workspaces, the admin ui doesn't use the workspace to correctly
distinguish them. In other words, if I set up 2 layers with the same
name but with different workspaces, clicking on them to get to the
layer configuration page navigates to the same layer in both cases.

I dug into this a little bit, and the catalog implementation that gets
used is the LocalWorkspaceCatalog. There's no thread local workspace
set when I trace through the code path, but it strips off the
workspace part of it when trying to find the layer. Here's the
relevant code:

    @Override
    public LayerInfo getLayerByName(String name) {
        if (LocalWorkspace.get() != null) {
            String wsName = LocalWorkspace.get().getName();

            //prefix the unqualified name
            if (name.contains(":")) {
                //name already prefixed, ensure it is prefixed with
the correct one
                if (name.startsWith(wsName+":")) {
                    //good to go, just pass call through
                    return wrap(super.getLayerByName(name));
                }
                else {
                    //JD: perhaps strip of existing prefix?
                }
            }

            //prefix it explicitly
            NamespaceInfo ns =
super.getNamespaceByPrefix(LocalWorkspace.get().getName());
            LayerInfo layer = super.getLayerByName(new
NameImpl(ns.getURI(), name));
            return wrap(layer);
        }
        return super.getLayerByName(name);
    }

    @Override
    public LayerInfo getLayerByName(Name name) {
        return getLayerByName(name.getLocalPart());
    }

The getLayerByName(Name) method is the one that gets called, and the
workspace part of the query is lost when it delegates to the
getLayerByName(String) method. If I instead only delegate when there
is a thread local workspace, it works for me.

    public LayerInfo getLayerByName(Name name) {
        if (LocalWorkspace.get() != null) {
            return getLayerByName(name.getLocalPart());
        } else {
            return super.getLayerByName(name);
        }
    }

If this is the right approach, I can submit a jira issue, and attach a
patch with a test.

Robert

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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.