Hi Jose, Yes, this is a known issue. The problem is that layers have no container. The idea is to add a container called a "map", or i think we maybe changed the name to "context". Anyways, it is a new configuration entity and would serve as the container for maps.
What you can do instead as a workaround is use a qualified layer name. For instance if you try to access a layer through the rest api that is prefixed by workspace name the api will recognize that. For instance: GET /layers/topp:states.xml will respect the "topp:" prefix. Even though the official name of the layer is just states. -Justin On Tue, Jan 11, 2011 at 2:24 AM, jose garcia <[email protected]> wrote: > Hi > > In GeoServer 2.0.2 with user interface is possible to configure two layers > with same name in different workspaces, but REST API methods to manage > layers seem only using the layer name, no workspace information. So no > possible to manage properly these layers with REST API. > > This seem a bug or restriction in REST API. Any chance to be solve in 2.1? > > Regards, > Jose García > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Geoserver-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-users > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial.
------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
