Nuno, have you considered going further and allowing each workspace to contain layers with different namespaces? Each workspace might have a default namespace, just like the global workspace, to aid backwards compatibility.
One additional change would be for each namespace to be configured with a namespace prefix as it would no longer be sufficient to take the name of the enclosing workspace, because each workspace could contain layers with different namespaces. Are workspaces and layers orthogonal concerns? Should a single layer be able to be published through multiple workspaces? This is the inverse of your use-case (multiple layers with the same feature type). Should workspaces be containers for layers or only containers for services? That is, should workspaces be like folders that own their contents, or should they be like a Eclipse workspaces that do not? (Attributes versus associations.) The use-cases that must be considered are not only publishing the same type more than once for app-schema, but workspace and layer access control. The users list has seen those with one workspace per client. This pattern is unusable for app-schema. I do not think that you have addressed the problem of an app-schema type-instance A which has a nested type-instance B from a different namespace. Would chaining of B be resolved in the same workspace first? This would suggest that A and B would both have to be in one workspace only. B might also be public. I have been using the term "layer" to mean a thing with data, and "type-instance" is I think pretty much the same thing: an instance of a feature type that is connected to some data. I do not want to use "type" by itself as we are considering making it non-unique. Apologies for the scope creep, but you are scratching the surface of a deeper problem. Other rats in the app-schema wood-pile are (1) the static singleton AppSchemaDataAccessRegistry, which knows each data access by its type only, not its workspace, and (2) the feature type cache, which assumes that types are equal if their names are equal. We have (2) because types in GML 3.2 and application schemas in general are cyclic graphs not trees so you cannot implement Object.equals for types by recursion (an instance of <https://en.wikipedia.org/wiki/Graph_isomorphism_problem>). What (2) means for you is that, if you want to publish two feature types with the same qualified name but from different incompatible versions of a schema, you might need a workspace-local feature type cache. Current rule is that we do not support more than one version of each schema in each GeoServer instance; I think we should keep this rule. Stop me now, I am just getting started! ;-) Kind regards, Ben. On 10/02/17 13:22, Nuno Oliveira 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 > > > > ------------------------------------------------------------------------------ > 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 > -- Ben Caradoc-Davies <[email protected]> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ 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
