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).
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?
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
+1 on the community module. Also +1 on having the parameter recognized based on parameter map, I think i ran into this type of thing a while back (can’t for the life of me remember what module though) and it would have been useful iirc.
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).
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?
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
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
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.