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.
>
------------------------------------------------------------------------------
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
