GeoServer
  1. GeoServer
  2. GEOS-3833

Links on Layer page lack workspace scoping

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.2
    • Component/s: Wicket UI
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The links created on the main "Layer" page in the UI do not include the workspace prefixes. Due to this we experienced issues with having different layers with the same name but in different workspaces. Each of the links will open the same layer (in our case the alphabetically first workspace, but that could be coincidence).

      To reproduce:
      Create two workspaces and a layer in each using the same name, e.g. one:myLayer and two:myLayer. Go to the "Layer" page from the menu and click on both links. They will both link to ".../geoserver/web/?wicket:bookmarkablePage=:org.geoserver.web.data.resource.ResourceConfigurationPage&name=myLayer". They should link to "...&name=one:myLayer" and "....&two:myLayer".

      Workaround:
      Hack the URL to include the workspace prefix for the layer.

        Activity

        Hide
        Peter Becker added a comment -

        I just noticed that deleting a layer seems to delete all layers of the same name, too. In the example deleting either "one:myLayer" or "two:myLayer" will delete both.

        Show
        Peter Becker added a comment - I just noticed that deleting a layer seems to delete all layers of the same name, too. In the example deleting either "one:myLayer" or "two:myLayer" will delete both.
        Hide
        Andrea Aime added a comment -

        Hum.... the issue runs a lot deeper. The very catalog subsystem has just one call to retrieve a layer, which is catalog.getLayerByName(name).

        Layers are simply not scoped by the workspace in the current setup. Not sure there is any way to solve this without performing significant changes in the code.
        Maybe we could have a catalog.getLayerByName(WorkspaceInfo, layerName) which looks into the associated ResourceInfo for workspace scoping.
        Justin, what do you think?

        Show
        Andrea Aime added a comment - Hum.... the issue runs a lot deeper. The very catalog subsystem has just one call to retrieve a layer, which is catalog.getLayerByName(name). Layers are simply not scoped by the workspace in the current setup. Not sure there is any way to solve this without performing significant changes in the code. Maybe we could have a catalog.getLayerByName(WorkspaceInfo, layerName) which looks into the associated ResourceInfo for workspace scoping. Justin, what do you think?
        Hide
        Andrea Aime added a comment -

        Hum... nope, I did not notice the catalog.getLayerByName(Name name) where the name can be namespace scoped.
        Ok, forget about the comment above, I just need to have the layer pages take not only a name but also a namespace prefix/workspace name

        Show
        Andrea Aime added a comment - Hum... nope, I did not notice the catalog.getLayerByName(Name name) where the name can be namespace scoped. Ok, forget about the comment above, I just need to have the layer pages take not only a name but also a namespace prefix/workspace name
        Hide
        Andrea Aime added a comment -

        Fixed on 2.0.x and trunk. Please try out Monday's nightly build here and double check if it's working for you too:
        http://gridlock.openplans.org/geoserver/2.0.x/

        Show
        Andrea Aime added a comment - Fixed on 2.0.x and trunk. Please try out Monday's nightly build here and double check if it's working for you too: http://gridlock.openplans.org/geoserver/2.0.x/
        Hide
        Justin Deoliveira added a comment -

        Sorry for the lack of comment on this one. I see it has been fixed. Just a two sense that I think the method getLayerByWorkspace() would be a good idea in the short term until we have a resource publishing split.

        Show
        Justin Deoliveira added a comment - Sorry for the lack of comment on this one. I see it has been fixed. Just a two sense that I think the method getLayerByWorkspace() would be a good idea in the short term until we have a resource publishing split.
        Hide
        Andrea Aime added a comment -

        In the end I actually used getLayerByName(Name). It requires some steps, as one has to grab the namespace from the workspace to create the qualified name. Not sure we want to add a getLayerByWorkspace if we plan to remove it soon.

        Show
        Andrea Aime added a comment - In the end I actually used getLayerByName(Name). It requires some steps, as one has to grab the namespace from the workspace to create the qualified name. Not sure we want to add a getLayerByWorkspace if we plan to remove it soon.

          People

          • Assignee:
            Andrea Aime
            Reporter:
            Peter Becker
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: