Hi Jody,
thanks for the feedback, please find my answers bellow:
On 11/15/2017 06:44 AM, Jody Garnett wrote:
Thanks Nuno, sorry we were a bit overrun when you emailed.
No worries.
I had some questions in today's meeting, mostly around the relationship with
global workspace. Andrea was able to clarify the user story, and that makes
sense to me.
Is there any reason to make this a separate setting? Would "turning off" global
be enough to enable this functionality?
This is unrelated to global workspaces. When publishing a complex feature type
it needs to be published (for several reasons) in a workspace that has the same
namespace of the root feature type.
This means that to publish the same complex feature type multiple times we need
to have several workspaces with different prefix but the same namespace.
Catalog related code is already capable of storying multiple namespaces as long
as they have a different prefix. The problem is that the catalog allow us to
query things
based solely on the namespace as a grouping concept, creating a /de facto/
relation ship of one to one between an workspace prefix and the associated
namespace.
So isolated workspaces brings the ability to handle catalog requests of the
sort when multiple workspace may have the same namespace, consider the
following request:
getResourceByName("{http:\\www.workspace.com
<http:%5C%5Cwww.workspace.com>}:layer1", ResourceType.class)
We are requesting /layer1/ that belongs to workspace associated to /namespace
//http:\\www.workspace.com <http:%5C%5Cwww.workspace.com>/.
If we have two workspaces with the same namespace both with a layer named
layer1 which one should be choose ?
This is were the limitation of the one to one relationship between workpsaces
and namespaces comes from.
The goal of isolated workspaces is to remove this limitation by:
1. between non isolated workspaces a namespace must be unique
2. no restrictions applied to isolated workspaces regarding namespaces
multiplicity
3. when a requested using the namespace as the grouping concept hits the catalog
1. if we are in the context of the global service then we go for the non
isolated workspace associated with the provided namespace, if no such workspace
exists then no resource is found
2. if we are int he context of an isolated workspace whose namespace
matches the desired namespace, then we substitute the namespace grouping
concept by the local workspace prefix
I am not too sure about CatalogCapabilities, I understand that the it is a
common design we use to allow implementations to negotiate what functionality
they support. It always makes me uncomfortable, breaking encapsulation and
forcing the use of conditional code. Is there a possibility of better defining
a method to avoid introducing this new class?
Well I couldn't find a better alternative and I'm open to suggestions, what
happens right now is that:
1. The DefaultCatalogFacade is perfectly able of storing and using the same
namespace with different prefix as a storing concept.
2. When retrieving a NameSpaceInfo object by the namespace URI isolated
namespaces need to be ignored, otherwise we will just get some random
NamespaceInfo object each time
For a catalog facade to support isolated workspaces the two points above need
to be respected. Unfortunately this requirements are on the implementation and
not on the API.
--
Jody Garnett
On 31 October 2017 at 02:29, Nuno Oliveira <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
A few months ago I started a thread [1] about allowing the definition of
several workspaces with the same namespace in GeoServer.
The main (root) use case for this is to allow the publishing of the same
complex feature type in GeoServer multiple times in different
workspaces. I finally had time to restart this work and can now give a more
concrete answers to some of the comments.
The workspace and namespaces relationship boils down to how things are
grouped together and stored in GeoServer catalog and the
ability to retrieve them. Let's say that we have an arbitrary resource in
GeoServer (layer, style, feature type, etc ...), that resource
can be retrieved like this:
1. getResourceByName("layer1", ResourceType.class)
2. getResourceByName("workspace:layer1", ResourceType.class)
3. getResourceByName("{http:\\www.workspace.com
<http:%5C%5Cwww.workspace.com>}:layer1", ResourceType.class)
The three ways above (there is more ways of doing this) are all valid ways
of referencing the same resource. The workspace name
and the workspace namespace are used interchangeably, this works fine
because there is a one to one relationship between them.
Some business code tend to use the workspace name, and other code like WFS
tend to use the namespace to reference a catalog
resource.
The concept of isolated workspaces (or namespaces) allow us to define
multiple workspaces with the same namespaces. The
resources of an isolated workspace can only be accessed in the context of
the virtual service of that workspace. Consider that
we have two workspaces with the same namespace:
1. Prefix: ws1, URI: *http://www.gs.com*, Isolated: false
2. Prefix: ws2, URI: *http://www.gs.com*, Isolated: true
And consider also that both workspaces have a feature type name
*complex_feature*. In the catalog point of view all this invocations
will return the feature_type belonging to first workspace:
* getResourceByName("complex_feature", FeatureType.class)
* getResourceByName("*ws1*:complex_feature", FeatureType.class)
* getResourceByName("{*http://www.gs.com
<http://www.gs.com>*}:complex_feature", FeatureType.class)
Only this invocation will retrieve the feature type belonging to the
isolated workspace (second one):
* getResourceByName("*ws2*:complex_feature", FeatureType.class)
If a resource is identified by its namespace URI the catalog will never be
able to find that resource if it belongs to an isolated
workspace, since the same namespace may be used by another workspace.
That's why we can only retrieve the content of an
isolated workspace from is virtual service, because if we are in the
context of a certain virtual service we can automatically
convert the namespace URI in a specific workspace name \ prefix.
The catalog machinery is quite complex [1] with several wrappers and
different catalog facades. To support workspaces isolation
we had to bring the concept of workspace isolation to the catalog facade
implementations and implement the necessary handling
in the local catalog wrapper.
The changes in the facade are really simple, *only one line of code* was
changed in DefaultCatalogFacadeImpl, we just need to make
sure that when we search a NameSpaceInfo by its URI namespaces that are
tied to an isolated workspace are ignored. The issue is that
if a particular catalog facade implementation doesn't do this change
isolated workspaces are not correctly supported.
To avoid backward compatibility issues I introduced the concept of
CatalogCapabilities (similar to Query capabilities in GeoTools), unless
a catalog facade or catalog implementation says explicitly that isolated
workspaces are supported this functionality will be disabled. This
can be reused to support the introduction of new catalog features and
avoiding breaking existing implementations.
The changes to support isolated workspaces are isolated int he catalog
machinery and transparent to all the other business code. This
is backward compatible and will not break existing implementations, of
curse if someone is using its own catalog facade implementation
isolated workspace will be disabled unless they implement the required
business code.
I have made some preliminary tests with WMS and WFS operations and
everything seems to be working as expected.
I hope this clarifies some of the doubts \ questions that were asked before.
Cheers,
[1]
http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html
<http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html>
[2]
https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom0tT9Epna8-mL31zS7Mo/edit?usp=sharing
<https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom0tT9Epna8-mL31zS7Mo/edit?usp=sharing>
--
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visithttp://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 <tel:+39%200584%20962313>
fax:+39 0584 1660272 <tel:+39%200584%20166%200272>
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.
------------------------------------------------------------------------------
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]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
<https://lists.sourceforge.net/lists/listinfo/geoserver-devel>
--
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
fax: +39 0584 1660272
http://www.geo-solutions.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.
------------------------------------------------------------------------------
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
