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:
- getResourceByName(String ns, String name, Class clazz);
- getResourceByName(NamespaceInfo ns, String name, Class clazz);
- getResourceByName(Name name, Class clazz);
All of this methods end up invoking the catalog facade method:
getResourceByName(NamespaceInfo namespace, String name, Class 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
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](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
fax: +39 0584 1660272
mob: +39 333 8128928
[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://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.
