On Fri, Apr 25, 2014 at 11:33 AM, Sampo Savolainen <
sampo.savolai...@spatineo.com> wrote:
> Hi,
>
> The XStreamPersister Andrea designed is working great for me after I made
> the small change I mentioned a few hours ago. But this still leaves part of
> the problem of feeding featuretype.xml configuration to DataStores /
> FeatureSources.
>
Good to hear. Btw, the XStreamPersister is Justin's work, I just did the
initializers plugins :-)
>
> The parsed metadata is part of the GS catalog FeatureTypeInfo and
> currently, I'm not aware of any mechanism to pass the metadata to the
> actual GT feature source.
>
>
> Here's a few approches I've thought of so far:
>
> 1. add a MetadataAware interface into GT:
>
> public interface MetadataAware {
> public void setMetadata(Map<String, ?> metadata);
> pblic Map<String, ?> getMetadata();
> }
>
> The setter would be called for FeatureSources which implement this
> interface when the FeatureSource is created, in
> FeatureTypeInfoImpl.getFeatureSource(). This is however clumsy as the
> FeatureSources are more often than not wrapped in other FeatureSources. And
> as there is no common abstract class, it's a lot of work implementing this
> for every wrapping FeatureSource, not to mention error-prone when new
> wrappers are written.
>
Yes, that's a common issue as we wrap feature sources a lot.
>
> 2. Add similar methods to SimpleFeatureSource. Most classes implement this
> anyway, so it would negate the issue of forgetting to implement an extra
> interface for FeatureSource implementations and wrappers.
>
Hmm... still fragile, not all wrappers might be aware of it, and it's
limited to simple features (like it or not, complex features are going to
grow).
>
> 3. Add the featuretype metadata in the GT FeatureType.userData. This is a
> crufty as this information is not really to do with the feature type, but
> the current layer based on this feature type. There's a strong possibility
> of things getting mixed up in situations where multiple layers are created
> from the same feature type.
>
Except you need a feature type to start with.
>
> Thoughts? Any better ideas that come to mind?
>
I would generalize and externalize what we are currently doing for
JDBCDataStores in ResourcePool:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L872
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L844
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L1112
That is, create a FeatureTypeInitializer interface that we can use to
delegate all types of special initializations, the
interface woudl act as a broker between the programmatic interfaces
provided by GeoTools and the configuration
stored in the feature type metadata maps
Cheers
Andrea
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
