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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ben Caradoc-Davies <[email protected]> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
