I know this is chiming in late but I can say that the whole concept of a
workspace was introduced so that we could de-couple it from the idea of a
WFS namespace, having the former be a layer grouping concept and the latter
being just an attribute of a layer, meaning no problem to share them
amongst workspaces.
That said, practically speaking Jody is correct and there is a bunch of
logic that has built up over time that relies on namespace as a grouping
concept so it will be interesting to see how hard those ties are to break.
On Wed, Feb 15, 2017 at 4:11 PM Jody Garnett <[email protected]> wrote:
I am concerned that if we do let multiple workspaces have the same
namespace we will break the default DescribeFeatureType behaviour which
assumes it can reply on namespace to keep name collisions out of the
generated GML. If this is not the case we may need to check for conflict
and modify the name during publishing ...
This feels like a pretty fundamental part of GeoServer WFS to be changing.
--
Jody Garnett
On 9 February 2017 at 16:22, Nuno Oliveira <[email protected]>
wrote:
Hi,
The main use case for this is to allow the publishing of the same feature
type in different virtual services, this is particularity important for
complex features (app-schema). Sometimes we want to map the same feature
type in a different way and publish it in different end points (virtual
services). Because a feature type is associated with a specific name space
and name spaces have a one to one relationship with workspaces, the only
way to this right now is to use several GeoServer instances.
When dealing with simple features or complex features there is two
different feature types concepts to take in account, one is the feature
type know by GeoTools (FeatureType) and the other one is the feature type
known by GeoServer (FeatureTypeInfo). The link between a GeoTools feature
type and a GeoServer feature type is the name. The name is composed by a
name space and the type name, for example "http://www.census.gov:tiger_roads";.
This link needs to be used for example when encoding features in WFS.
In GeoServer, workspaces have a name and a name space. When a resource is
created it inherits is workspace name space. For example, if we create a
workspace named tiger with name space (URI) http://www.census.gov and
create a vector layer named tiger_roads inside the tiger workspace, the
layer feature type (FeatureTypeInfo) name will be
"http://www.census.gov:tiger_roads";. The link needed between GeoTools and
GeoServer feature types described above is the main reason for the one to
one relationship limitation between workspaces and name spaces, for WFS
there is no workspaces only name spaces.
Did I understood this relationships correctly so far ?
More in detail, when creating an workspace in GeoServer two objects are
actually created: the WorkspaceInfo and a NameSpaceInfo. The first object
contains basically the workspace name and the second object contains the
workspace name (prefix) and the workspace name space (URI).
At the lowest level in GeoServer resources are searched by the
NameSpaceInfo ID and the resource name. The catalog API give us three ways
to lookup for resources by their name:
1. getResourceByName(String ns, String name, Class<T> clazz);
2. getResourceByName(NamespaceInfo ns, String name, Class<T> clazz);
3. getResourceByName(Name name, Class<T> clazz);
All of this methods end up invoking the catalog facade method:
getResourceByName(NamespaceInfo namespace, String name, Class<T> clazz);
When no NameSpaceInfo is provided (case 1 and 3) the NameSpaceInfo will be
searched or by the workspace name or by the name space URI:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/impl/CatalogImpl.java#L441-L461
<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/impl/CatalogImpl.java#L441-L461>
<https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/impl/CatalogImpl.java#L441-L461>And
this is where the one to one relationship between workspaces and schema
name spaces comes in. If multiple workspaces had the same URI when
searching a NameSpaceInfo by the URI we will end up with multiple
NameSpaceInfo with different prefix (workspaces names).
Dis I mis anything here ?
A possible solution to allow several workspaces to share the same name
space is the concept of isolated workspaces. Resources of isolated
workspaces can only be used\accessed in the context of virtual services for
that workspace but isolated workspaces can have the same URI of other
workspaces (isolated or not). When looking for a NameSpaceInfo by the URI
two situations can happen:
- if we are in the context of virtual service and the local workspace
URI match the desired URI we return the NameSpaceInfo associated to our
workspace, otherwise we perform a normal search ignoring all the others
isolated workspaces;
- if we are not in the context of a virtual service we perform a normal
search ignoring all the isolated workspaces;
The new isolated workspaces logic can be implemented in the already
existing LocalWorkspace catalog wrapper.
Isolated workspaces will allow the same feature type to be published
several times in different workspaces.
Opinions on this ?
Regards,
Nuno Oliveira
--
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==
Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313 <+39%200584%20962313>
fax: +39 0584 1660272 <+39%200584%20166%200272>
mob: +39 333 8128928 <+39%20333%20812%208928>
http://www.geo-solutions.ithttp://twitter.com/geosolutions_it
-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono
da considerarsi strettamente riservate. Il loro utilizzo è consentito
esclusivamente al destinatario del messaggio, per le finalità indicate
nel messaggio stesso. Qualora riceviate questo messaggio senza esserne
il destinatario, Vi preghiamo cortesemente di darcene notizia via e
-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo
anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario
ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely
for the attention and use of
the named addressee(s) and may be confidential or proprietary in
nature or covered by the provisions of privacy act (Legislative Decree
June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not
in accord with its purpose, any disclosure, reproduction, copying,
distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The
sender does not give any warranty or accept liability as the content,
accuracy or completeness of sent messages and accepts no
responsibility for changes made after they were sent or for other
risks which
arise as a result of e-mail transmission, viruses, etc.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
