We may be talking about different things, I am talking about datastore
connection parameter constants defined in WFSDataStoreFactory. They are
explicitly referenced via an import statement in a couple GeoServer files.
For the current use of WFSDataStore we would be able to inline these values.
It sounds like a dependency to wfs-ng is needed for your branch. Are your
parameters part of DataStore construction or are they additional Query
parameters?
Jody Garnett
On Mon, Jun 23, 2014 at 4:59 PM, Sampo Savolainen <
[email protected]> wrote:
> Hi,
>
> The configuration for a cascaded stored query specifies how the parameters
> for a cascaded request are mapped from viewparams (as SQL views), defaults,
> and the context of the original query (query envelope, for example).
>
> So a layer created from a cascaded stored query might define:
> "The value of parameter X is defined as ('minimum X value of query
> envelope' + 'maximum X value of query envelope') / 2 "
> "The value of parameter Z is 'foo' "
>
> This is done via the classes in my tree of gt-wfs-ng, package
> org.geotools.data.wfs.internal.v2_0.storedquery. These classes are
> persisted in featuretype.xml and the configuration is set up in the UI, so
> the classes must be available (somehow) for the UI to work. As the classes
> are in gt-wfs-ng, the requirement that geoserver work with either gt-wfs or
> gt-wfs-ng plugged in, is a big problem.
>
> Does this help or are we talking about different things?
>
>
> Sampo
>
>
>
> On Mon, Jun 23, 2014 at 9:47 AM, Jody Garnett <[email protected]>
> wrote:
>
>> Let me check..
>>
>> Factory is used in:
>> - RemoteOWSTestSupport: Just a test so it can have a direct dependency.
>> Checking the details the factory is used both directly and for the
>> parameter keys. No reason not to inline the keys and use datastore finder
>> - GetMapKvpRequestReader: same deal, used for parameter keys and could be
>> replaced
>>
>> WFSDataStore interface: not used directly in GeoServer
>> WFS_1_0_0_DataStore: not used directly in GeoServer
>> WFS_1_1_0_DataStore: not used directly in GeoServer
>> WFSTransactionState: not used directly by GeoServer
>>
>> So perhaps you can be more specific?
>>
>>
>> Jody Garnett
>>
>>
>> On Mon, Jun 23, 2014 at 3:51 PM, Sampo Savolainen <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> By "constants", were you referring to the parameter classes? The classes
>>> I'm talking about are proper real live classes which are used to configure
>>> how stored query parameters are derived from the query. These are much more
>>> complex than constants.
>>>
>>>
>>> Sampo
>>>
>>>
>>> On Mon, Jun 23, 2014 at 12:28 AM, Jody Garnett <[email protected]>
>>> wrote:
>>>
>>>> We do not have that many references to these constants, consider using
>>>> "inline" with a TODO comment to switch it back after the migration is
>>>> complete. Has the advantage of being easy/quick.
>>>>
>>>> Jody Garnett
>>>>
>>>>
>>>> On Mon, Jun 23, 2014 at 6:13 AM, Sampo Savolainen <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Good point. We can compile my current branch as-is if we depend on
>>>>> gt-wfs-ng as a provided dependency, but that won't stop things from
>>>>> breaking at runtime. The classes that are used to define the values of
>>>>> stored query parameters currently reside in gt-wfs-ng, so this would need
>>>>> to be refactored for the drop-in replacement idea to work in my case.
>>>>>
>>>>> Just to throw out some ideas:
>>>>> 1) The parameter classes could be moved to geoserver so they would be
>>>>> available regardless if the user uses wfs or wfs-ng. This would however
>>>>> place the burden of resolving the parameters into gs instead of gt-wfs-ng
>>>>> and would reduce the usefulness of the stored query support in standalone
>>>>> gt (i.e. without geoserver)
>>>>> 2) The parameter classes could be moved somewhere closer to gt core
>>>>> so they would be available regardless if wfs or wfs-ng is plugged in.
>>>>> 3) UI code relating to the stored query configuration can be wrapped
>>>>> with reflection and Class.forName() and protected so it will work
>>>>> regardless wfs or wfs-ng is in use
>>>>>
>>>>> Option 1 is less than optimal design wise as it would lessen the
>>>>> usefulness of cascaded stored query sources. Option 3 would require a lot
>>>>> of tip-toeing around and we would end up with somewhat dirty code. This is
>>>>> especially unfortunate as this affects a core UI view. Option 2 feels best
>>>>> from my view.
>>>>>
>>>>> Thoughts? If you feel option 2 is the way to go, I'd appreciate ideas
>>>>> regarding where the parameter classes should be stored in.
>>>>>
>>>>>
>>>>> Sampo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 18, 2014 at 11:36 AM, Andrea Aime <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> On Tue, Jun 17, 2014 at 6:36 PM, Justin Deoliveira <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>> Cool, I think for now what I'll do is proceed with making wfs-ng a
>>>>>>> pure drop in and package it up as a community module for geoserver.
>>>>>>> Along
>>>>>>> with it documentation that specifies installing it requires removing the
>>>>>>> old one**. And then once we are more confident with it and it has seen
>>>>>>> some
>>>>>>> more user testing we can perhaps perform the switch and make it the
>>>>>>> default, packaging up the original as an extension.
>>>>>>>
>>>>>>
>>>>>> No objection personally, but I'm wondering how that will affect
>>>>>> Sampo's work.
>>>>>> I supposedhis pull request won't even compile if we are not depending
>>>>>> on wfs-ng?
>>>>>> https://github.com/geoserver/geoserver/pull/611
>>>>>>
>>>>>> Cheers
>>>>>> Andrea
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ==
>>>>>> GeoServer Professional Services from the experts! Visit
>>>>>> http://goo.gl/NWWaa2 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
>>>>> [email protected]
>>>>> +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.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>>>>> Solutions
>>>>> Find What Matters Most in Your Big Data with HPCC Systems
>>>>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>>>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>>>> http://p.sf.net/sfu/hpccsystems
>>>>> _______________________________________________
>>>>> Geoserver-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Sampo Savolainen
>>> R&D Director, Spatineo Oy
>>> [email protected]
>>> +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.
>>>
>>
>>
>
>
> --
> Sampo Savolainen
> R&D Director, Spatineo Oy
> [email protected]
> +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.
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
