> Hi,
> I'd like to request a new community module to store the dependencies
> and a custom GUI to configure the geotools feature aggregating data store.
>
> The idea is to play with both a bit on trunk and when they are ready port
> to supported status/extension status, while at the same time backport
> them to the stable series (2.7.x/trunk).
Sounds good.
> Btw, the aggregating store needs a GeoTools repository parameter.
> I guess the cleanest way to handle this kind of parameter would be to
> instantiate the already existing bridge, CatalogRepository, once
> in the spring context, and have the resource pool recognize the
> parameter just like it does for namespace, and automatically inject the
> shared one into the parameter map.
>
> Opinions?
I ran into some trouble with the Repository interface being "incomplete" when I
was trying to document it. If you have any feedback on its use when
implementing feature-aggregate can we discuss it on geotools-devel.
Jody
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
