On Fri, Apr 25, 2014 at 5:34 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Fri, Apr 25, 2014 at 4:16 PM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> We don't wrap stores at the ResourcePool level, if we do, it's
>>> happening higher level in the security
>>> wrappers. ResourcePool gets the stores from the factories directly,
>>> there are no intermediaries that
>>> I'm aware of, just check the getDataStore code paths.
>>>
>>
>> When I debugged this, my dataStore was wrapped as a RetypingDataStore.
>> Check DataStoreUtils.getDataAccess()
>>
>
> Ah, you're right, forgot about it, your store must be emitting invalid
> names (names with : inside), something that indeed
> with JDBC store is possible, but very unlikely.
>
Ah yes. As I'm using the stored query ids as type names, which are uris, I
am emitting invalid names. Do you think this is will become a problem?
Should I remap them in the extension or is it fine to let GS create the
RetypingDataSource?
As this would be a mechanism to provide extension specific metadata to
>> configured features, it would make sense that the FeatureTypeInfo should
>> exist when this mechanism is used. Also, GeoServerFeatureSource.create() is
>> used only in ResourcePool.getFeatureSource() - which is definitely a case
>> where the feature type exists.
>>
>
> Nope, ResourcePool.getFeatureSource creates the feature type for virtual
> tables, the feature type does not exist in the store before
> we call addVirtualTable.
>
Ok. Fair enough. The counter-argument here is though, that in such cases
the user has not had a chance (yet) to create such configuration, so the
empty metadata is fine. It's more of a problem though that in the case of
JDBC Views, the data here would be the metadata of the "parent" feature
type, if I understood the design correctly.
Yeah. We don't want to add something that will only be used for wfs-ng. I
>> would however argue, that the reason nobody else has yet wondered about
>> this problem is because before pluggable XStreamParsersInitializers, the
>> extensions were themselves in charge of configuration files and they didn't
>> have to to pipe their config from pure generic GS to GT. Now that the
>> pluggable mechanism makes this a possibility, I see a strong case that
>> other extensions might want to opt for something like this.
>>
>
> I don't buy this, personally I don't remember anybody ever asking or
> experssing interest on the subject. The way I see it, stored queries are
> pretty unique to the WFS 2.0 specification. Do you know of other data
> sources in the wild that limit access to the store the same way? Make me
> just a single example and I'll be with you about supporting this use case.
>
Passing configuration from GS to an GT extension is not specific to wfs-ng
or other "limited access" sources. It should be easy to argue that many
data stores require more configuration than is provided in vanilla
featuretype.xml.
When I was asking about plugin configuration two weeks back, Jody said: "Other
data stores, such as pregeneralization, or app-schema, make use of their
own config files which are passed in as a datastore parameter.". You then
came up the idea of the pluggable XML parsers, which I read as a sign that
you were not 100% comfortable with the idea that data stores must take care
of the configuration files themselves. I then applied your model to store
configuration. What I'm now asking is how the configuration data the
parsers produce passed to the actual extension.
I'm not entirely sure what you're not buying here? Maybe we've accidentally
started talking past each other?
Anyways, the mechanism I talked about will be created the day I find time
> to introduce feature type restructuring via TransformFeatureSource it will
> be needed (but it will be my problem, along with fixing DataStoreUtils).
>
Great. I'll look forward to this refactor!
> Can we see a diff? Looking for the changes inspecting the source code is
> pretty inefficient.
>
https://github.com/sampov2/geoserver/commit/22e01d28f13d536c1fcc1657a6a8fa0716489bb8
https://github.com/sampov2/geotools/commit/258b099a5b9174d1b3eeca69a6dd98754cc4815d
(The GT commit is unfortunately a bit muddled up by a refactor of the
configuration beans. Just look at how the StoredQueryConfiguration object
is looked up)
S.
> 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
>
> -------------------------------------------------------
>
--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
