Hi,
On a related note. I'm slightly confused to how current master of gt + gs
should work. I'm trying to get wfs-ng working ("activated"), but I'm not
getting much traction. Master (pure, not my branch) with the old wfs module
seems to work fine, but If I switch the modules (remove gt-wfs, add
gt-wfs-ng), server startup will fail:
23 Jun 12:51:12 WARN [support.DisposableBeanAdapter] - Invocation of
destroy method failed on bean with name 'geoServerLoader':
org.springframework.beans.factory.BeanCreationNotAllowedException: Error
creating bean with name 'GWCLifeCycleHandler': Singleton bean creation not
allowed while the singletons of this factory are in destruction (Do not
request a bean from a BeanFactory in a destroy method implementation!)
23 Jun 12:51:12 ERROR [context.ContextLoader] - Context initialization
failed
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'wfsDataStorePanel' defined in URL
[jar:file:/home/savolais/twosix/geoserver-2.6-SNAPSHOT/webapps/geoserver/WEB-INF/lib/gs-web-core-2.6-SNAPSHOT.jar!/applicationContext.xml]:
Initialization of bean failed; nested exception is
org.springframework.beans.TypeMismatchException: Failed to convert property
value of type 'java.lang.String' to required type 'java.lang.Class' for
property 'factoryClass'; nested exception is
java.lang.IllegalArgumentException: Cannot find class
[org.geotools.data.wfs.WFSDataStoreFactory]
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
Is current master broken or am I missing something?
S.
On Mon, Jun 23, 2014 at 11:42 AM, Sampo Savolainen <
[email protected]> wrote:
> Hi Jody,
>
> Yes, we've managed to talk about different things. The parameters I'm
> talking about are not parameters for the data store, but configuration
> classes that dictate how cascaded stored queries are executed. For every
> layer based on cascaded stored queries, there is configuration relatively
> similar to SQL views. In this case, the configure defines what Stored Query
> Parameters are sent via each cascaded request. This method can be used to
> define both static and dynamic values for the parameters (via CQL
> expressions).
>
> The parameters are stored in featuretype.xml as layer metadata and are
> passed on as query hints (as with SQL views). The data store then reads
> these hints and uses them, the query and user supplied viewparams to
> construct the parameters sent with the stored query request.
>
> Like I mentioned earlier, the classes are needed in geoserver so the UI
> may manipulate these objects (and serialize/deserialize objects from the
> data directory).
>
>
> S.
>
>
>
>
> On Mon, Jun 23, 2014 at 10:15 AM, Jody Garnett <[email protected]>
> wrote:
>
>> 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.
>>>
>>
>>
>
>
> --
> 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
