app-schema needs a better way of registering DataAccess instances, which must collaborate with each other to perform feature chaining. At the moment, we have an AppSchemaDataAccessRegistry. When we understand the Repository API, we might use it.
Because feature chaining *requires* collaboration between DataAccess instances in different namespaces, and because GeoServer *requires* the workspace name to be equal to the namespace prefix (GEOS-3042), cross-workspace communication is *required* for Christian's code to be useful for feature chaining.
This may be an indication that, because in effect GeoServer has bound together the concepts of namespace and workspace, the utility of workspaces has been lost. Surely they were there to separate groups of data? If our DataAccesses are forced apart into separate workspaces and we then have to use a repository to allow them to communicate, workspaces serve no function.
I think the GeoServer catalog as implemented is a work in progress. Repository work should be informed by the future plans of the GeoServer catalog. Justin?
Copying the geoserver list. Yes, Jody, I am a naughty cc: spammer. Again. Might as well just cc: everyone in my address book.
Jody Garnett wrote:
Bleck - sorry about the trouble Andrea.
getFeatureSources method from the repository.
The problem here is that the semantics is not clear to me. There are data
store names, ids, namespaces, workspaces, prefixes and I have no idea what
is what for geotools and geoserver.This seems to a be a problem with the information model presented by
GeoServer. Christian I remain unconvinved that you should be allowing
your code to reference DataStore from multiple GeoServer workspaces; I
think they are designed be to separate.That is however a discussion for the geoserver-devel list.
Sorry, I will leave up this problem to Jody.
The only thing I could do is to add a method "getDataStores" returning all
datastores and ValidationRunner can do his job.That seems to be what is needed; here is my "definition" for it:
/**
* List of available DataStore instances; these are considered to be
* live/connected datastores under the management of the application
* and should not be closed or otherwise harmed by client code.
* <p>
*
* @return List of Managed DataStore instances
*/
public List<DataStore> getDataStores();Jody, for my registry implementations you could simply implement a method
throwing an "UnsupportedOperationException", I will investigate later.Will do - thanks.
In reviewing your DSFinderRepository I notice you have almost the
exact same design as that of DefaultRepository (helper methods to load
in shapefiles; or other datastores indicated by properties files etc).Jody
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
