Hello Nuno,
For the most part, the functionality described seems like a feasible
addition.
I do have a few questions about implementation:
1. What sort of configuration object(s) will these isolated workspaces
be? NamespaceInfo + WorkspaceInfo, or something different?
2. How is an isolated workspace defined? Or in other words, what
distinguishes an isolated workspace from a regular workspace?
3. How is an isolated workspace identified in the UI? In the REST API?
And some questions about edge-cases:
1. How does the WMS with a virtual workspace works with isolated works
2. What happens if you try to set an isolated workspace as the default
workspace?
3. Assuming you have a regular workspace and an isolated workspace with
the same namespace, if you delete the regular workspace what happens to the
isolated workspace? Is it still an isolated workspace?
Torben
On Tue, Nov 14, 2017 at 10:44 PM, Jody Garnett <[email protected]>
wrote:
> Thanks Nuno, sorry we were a bit overrun when you emailed.
>
> 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?
>
> 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?
>
> --
> Jody Garnett
>
> On 31 October 2017 at 02:29, Nuno Oliveira <[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}: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 <http://www.gs.com>*,
>> Isolated: false
>> 2. Prefix: ws2, URI: *http://www.gs.com <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-worksp
>> aces-to-use-the-same-name-space-URI-td5307302.html
>> [2] https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom
>> 0tT9Epna8-mL31zS7Mo/edit?usp=sharing
>>
>> --
>> 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>
>> 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
