[Geoserver-devel] App-Schema PropertySelectionTest taking down the build

GeoServer GeoServer Developer
1

The test results are here:

Example:

junit.framework.AssertionFailedError: expected:<1> but was:<0>
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.failNotEquals(Assert.java:280)
	at junit.framework.Assert.assertEquals(Assert.java:64)
	at junit.framework.Assert.assertEquals(Assert.java:198)
	at junit.framework.Assert.assertEquals(Assert.java:204)
	at org.geoserver.test.AbstractAppSchemaWfsTestSupport.assertXpathCount(AbstractAppSchemaWfsTestSupport.java:350)
	at org.geoserver.test.PropertySelectionTest.testGetFeature(PropertySelectionTest.java:44)

–
Jody Garnett

2

It looks like the failures started when Andrea and Alessio made a bunch of CSW changes.

git diff db351e333fec5047bb2^ c03ce370f3a8da00

I am investigating. I hope it isn't the jxpath crosstalk between unrelated modules I warned Andrea about last night ...

On 18/09/12 09:25, Jody Garnett wrote:

The test results are here:
- http://hudson.opengeo.org/hudson/job/geoserver-master/5462/console
- http://hudson.opengeo.org/hudson/job/geoserver-master/ws/src/extension/app-schema/app-schema-test/target/surefire-reports/org.geoserver.test.PropertySelectionTest.txt

Example:

junit.framework.AssertionFailedError: expected:<1> but was:<0>
  at junit.framework.Assert.fail(Assert.java:47)
  at junit.framework.Assert.failNotEquals(Assert.java:280)
  at junit.framework.Assert.assertEquals(Assert.java:64)
  at junit.framework.Assert.assertEquals(Assert.java:198)
  at junit.framework.Assert.assertEquals(Assert.java:204)
  at org.geoserver.test.AbstractAppSchemaWfsTestSupport.assertXpathCount(AbstractAppSchemaWfsTestSupport.java:350)
  at org.geoserver.test.PropertySelectionTest.testGetFeature(PropertySelectionTest.java:44)

--
Jody Garnett

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

3

Jody,

I have a workaround in final testing.

I am not sure why, but it seems that Andrea's changes in 4615daa694a5d84e4270a89f78cf8cc4a58a5206 as a side-effect appear to turn on CITE compliance for this test. (And only this test? Why?)

The symptom is that in the test fixture a WFS request to a WFS service URL fails if it has a VERSION but no SERVICE parameter. For example, this silently fails:

getAsDOM("wfs?&version=1.1.0&request=GetFeature ...

This succeeds:

getAsDOM("wfs?service=WFS&version=1.1.0&request=GetFeature ...

My workaround is to add the SERVICE parameter for this test.

Andrea, can you see how your changes might have caused this behaviour? I think there might have been an oversight in the way the dispatcher is invoked by spring. I tried commenting out your Dispatcher changes but that did not help. Please check as it might cause other unintended changes.

Here is the commit that seems to be related:

******

commit 4615daa694a5d84e4270a89f78cf8cc4a58a5206
Author: Andrea Aime <andrea.aime@anonymised.com>
Date: Sun Sep 16 16:57:37 2012 +0200

     Making CSW GetCapabilities and DescribeRecord CITE compliant

******

Mostly CSW, but it also changes these:
src/main/src/main/java/org/geoserver/ows/CiteComplianceHack.java
src/main/src/test/java/applicationContext.xml
src/ows/src/main/java/org/geoserver/ows/Dispatcher.java
src/wfs/src/main/java/applicationContext.xml
src/wfs/src/main/java/org/geoserver/wfs/CiteComplianceHack.java

At least it looks like a spring problem, not an unfixable jxpath problem. :slight_smile:

Kind regards,
Ben.

On 18/09/12 10:49, Ben Caradoc-Davies wrote:

It looks like the failures started when Andrea and Alessio made a bunch
of CSW changes.

git diff db351e333fec5047bb2^ c03ce370f3a8da00

I am investigating. I hope it isn't the jxpath crosstalk between
unrelated modules I warned Andrea about last night ...

On 18/09/12 09:25, Jody Garnett wrote:

The test results are here:
- http://hudson.opengeo.org/hudson/job/geoserver-master/5462/console
- http://hudson.opengeo.org/hudson/job/geoserver-master/ws/src/extension/app-schema/app-schema-test/target/surefire-reports/org.geoserver.test.PropertySelectionTest.txt

Example:

junit.framework.AssertionFailedError: expected:<1> but was:<0>
  at junit.framework.Assert.fail(Assert.java:47)
  at junit.framework.Assert.failNotEquals(Assert.java:280)
  at junit.framework.Assert.assertEquals(Assert.java:64)
  at junit.framework.Assert.assertEquals(Assert.java:198)
  at junit.framework.Assert.assertEquals(Assert.java:204)
  at org.geoserver.test.AbstractAppSchemaWfsTestSupport.assertXpathCount(AbstractAppSchemaWfsTestSupport.java:350)
  at org.geoserver.test.PropertySelectionTest.testGetFeature(PropertySelectionTest.java:44)

--
Jody Garnett

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

4

John can you confirm this fixed your downstream build?

–
Jody Garnett

On Tuesday, 18 September 2012 at 2:41 PM, Ben Caradoc-Davies wrote:

Jody,

I have a workaround in final testing.

I am not sure why, but it seems that Andrea’s changes in
4615daa694a5d84e4270a89f78cf8cc4a58a5206 as a side-effect appear to turn
on CITE compliance for this test. (And only this test? Why?)

The symptom is that in the test fixture a WFS request to a WFS service
URL fails if it has a VERSION but no SERVICE parameter. For example,
this silently fails:

getAsDOM("wfs?&version=1.1.0&request=GetFeature …

This succeeds:

getAsDOM("wfs?service=WFS&version=1.1.0&request=GetFeature …

My workaround is to add the SERVICE parameter for this test.

Andrea, can you see how your changes might have caused this behaviour? I
think there might have been an oversight in the way the dispatcher is
invoked by spring. I tried commenting out your Dispatcher changes but
that did not help. Please check as it might cause other unintended changes.

Here is the commit that seems to be related:

commit 4615daa694a5d84e4270a89f78cf8cc4a58a5206
Author: Andrea Aime <andrea.aime@anonymised.com>
Date: Sun Sep 16 16:57:37 2012 +0200

Making CSW GetCapabilities and DescribeRecord CITE compliant

Mostly CSW, but it also changes these:
src/main/src/main/java/org/geoserver/ows/CiteComplianceHack.java
src/main/src/test/java/applicationContext.xml
src/ows/src/main/java/org/geoserver/ows/Dispatcher.java
src/wfs/src/main/java/applicationContext.xml
src/wfs/src/main/java/org/geoserver/wfs/CiteComplianceHack.java

At least it looks like a spring problem, not an unfixable jxpath
problem. :slight_smile:

Kind regards,
Ben.

On 18/09/12 10:49, Ben Caradoc-Davies wrote:

It looks like the failures started when Andrea and Alessio made a bunch
of CSW changes.

git diff db351e333fec5047bb2^ c03ce370f3a8da00

I am investigating. I hope it isn’t the jxpath crosstalk between
unrelated modules I warned Andrea about last night …

On 18/09/12 09:25, Jody Garnett wrote:

The test results are here:

Example:

junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:280)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:198)
at junit.framework.Assert.assertEquals(Assert.java:204)
at org.geoserver.test.AbstractAppSchemaWfsTestSupport.assertXpathCount(AbstractAppSchemaWfsTestSupport.java:350)
at org.geoserver.test.PropertySelectionTest.testGetFeature(PropertySelectionTest.java:44)

–
Jody Garnett

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

5

Hey,

No it didn’t seem to fix our downstream app: still having that same issue of the metaTileCache bean failing, here is some more output:

18 Sep 15:22:08 INFO [org.geoserver] - Loaded service ‘wms’, enabled
18 Sep 15:22:08 INFO [org.geoserver] - Loaded service ‘wfs’, disabled
18 Sep 15:22:08 INFO [org.geoserver] - Loaded service ‘wcs’, disabled
18 Sep 15:22:09 WARN [support.DisposableBeanAdapter] - Invocation of destroy method failed on bean w
ith name ‘geoServerLoader’: org.springframework.beans.factory.BeanCreationNotAllowedException: Error
creating bean with name ‘metaTileCache’: Singleton bean creation not allowed while the singletons o
f this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method impl
ementation!)
18 Sep 15:22:09 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘wmsGetMap’ d
efined in URL [jar:file:/C:/Users/jhudson/.m2/repository/org/geoserver/wms/2.3-SNAPSHOT/wms-2.3-SNAP
SHOT.jar!/applicationContext.xml]: Cannot resolve reference to bean ‘filterFactory’ while setting be
an property ‘filterFactory’; nested exception is org.springframework.beans.factory.NoSuchBeanDefinit
ionException: No bean named ‘filterFactory’ is defined…

you can see we are not using WFS or WCS, only WMS, but im not even sure where this error begins… Spring somewhere…

Thanks,

John

On Tue, Sep 18, 2012 at 3:02 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

John can you confirm this fixed your downstream build?

–
Jody Garnett

On Tuesday, 18 September 2012 at 2:41 PM, Ben Caradoc-Davies wrote:

Jody,

I have a workaround in final testing.

I am not sure why, but it seems that Andrea’s changes in
4615daa694a5d84e4270a89f78cf8cc4a58a5206 as a side-effect appear to turn
on CITE compliance for this test. (And only this test? Why?)

The symptom is that in the test fixture a WFS request to a WFS service
URL fails if it has a VERSION but no SERVICE parameter. For example,
this silently fails:

getAsDOM("wfs?&version=1.1.0&request=GetFeature …

This succeeds:

getAsDOM("wfs?service=WFS&version=1.1.0&request=GetFeature …

My workaround is to add the SERVICE parameter for this test.

Andrea, can you see how your changes might have caused this behaviour? I
think there might have been an oversight in the way the dispatcher is
invoked by spring. I tried commenting out your Dispatcher changes but
that did not help. Please check as it might cause other unintended changes.

Here is the commit that seems to be related:

commit 4615daa694a5d84e4270a89f78cf8cc4a58a5206
Author: Andrea Aime <andrea.aime@anonymised.com>
Date: Sun Sep 16 16:57:37 2012 +0200

Making CSW GetCapabilities and DescribeRecord CITE compliant

Mostly CSW, but it also changes these:
src/main/src/main/java/org/geoserver/ows/CiteComplianceHack.java
src/main/src/test/java/applicationContext.xml
src/ows/src/main/java/org/geoserver/ows/Dispatcher.java
src/wfs/src/main/java/applicationContext.xml
src/wfs/src/main/java/org/geoserver/wfs/CiteComplianceHack.java

At least it looks like a spring problem, not an unfixable jxpath
problem. :slight_smile:

Kind regards,
Ben.

On 18/09/12 10:49, Ben Caradoc-Davies wrote:

It looks like the failures started when Andrea and Alessio made a bunch
of CSW changes.

git diff db351e333fec5047bb2^ c03ce370f3a8da00

I am investigating. I hope it isn’t the jxpath crosstalk between
unrelated modules I warned Andrea about last night …

On 18/09/12 09:25, Jody Garnett wrote:

The test results are here:

Example:

junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:280)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:198)
at junit.framework.Assert.assertEquals(Assert.java:204)
at org.geoserver.test.AbstractAppSchemaWfsTestSupport.assertXpathCount(AbstractAppSchemaWfsTestSupport.java:350)
at org.geoserver.test.PropertySelectionTest.testGetFeature(PropertySelectionTest.java:44)

–
Jody Garnett

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

6

John, the change made by Andrea included moving a reference to a filterFactory bean from wfs to main.

On 18/09/12 14:34, John Hudson wrote:

18 Sep 15:22:09 ERROR [context.ContextLoader] - Context initialization
failed
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'wmsGetMap' d
efined in URL
[jar:file:/C:/Users/jhudson/.m2/repository/org/geoserver/wms/2.3-SNAPSHOT/wms-2.3-SNAP
SHOT.jar!/applicationContext.xml]: Cannot resolve reference to bean
'filterFactory' while setting be
an property 'filterFactory'; nested exception is
org.springframework.beans.factory.NoSuchBeanDefinit
ionException: No bean named 'filterFactory' is defined...

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

7

On Tue, Sep 18, 2012 at 6:41 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Jody,

I have a workaround in final testing.

I am not sure why, but it seems that Andrea’s changes in 4615daa694a5d84e4270a89f78cf8cc4a58a5206 as a side-effect appear to turn on CITE compliance for this test. (And only this test? Why?)

The relevant changes are here:

@@ -678,6 +678,7 @@ public class Dispatcher extends AbstractController {
// sure the “mandatory” parameters are specified, even though we
// succesfully dispatched the request.
if (citeCompliant) {

  • // the version is mandatory for all requests but GetCapabilities
    if (!“GetCapabilities”.equalsIgnoreCase(req.getRequest())) {
    if (req.getVersion() == null) {
    //must be a version on non-capabilities requests
    @@ -709,12 +710,13 @@ public class Dispatcher extends AbstractController {
    “InvalidParameterValue”, “version”);
    }
    }
  • if (req.getService() == null) {
  • //give up
  • throw new ServiceException(“Could not determine service”,
  • “MissingParameterValue”, “service”);
  • }
  • }
  • // the service is mandatory for all requests instead
  • if (req.getService() == null) {
  • //give up
  • throw new ServiceException(“Could not determine service”,
  • “MissingParameterValue”, “service”);
    }
    }

@@ -828,15 +830,20 @@ public class Dispatcher extends AbstractController {
}

if (responses.isEmpty()) {

  • String msg = "No response: ( object = " + result.getClass();
  • if (req.getOutputFormat() != null) {
  • msg += (", outputFormat = " + req.getOutputFormat());
  • if(req.getOutputFormat() != null) {
  • throw new ServiceException("Failed to find response for output format " + req.getOutputFormat(),
  • ServiceException.INVALID_PARAMETER_VALUE, “outputFormat”);
    :

Both changes are there to make GeoServer CITE compliant, the CSW exercises a couple of behavior
that are mandated, but not exercised by other CITE test suites:

  • the service parameter is compulsory regardless of the request type
  • when the output format is present but wrong the service exception must refer to it in the
    service exception

Did not look at the tests, but the first behavior triggers only in cite compliance mode, so I
guess the test in question is actually running in cite compliance mode, though I cannot see why
that is happening

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

8

On Tue, Sep 18, 2012 at 8:34 AM, John Hudson <johnathon.hudson@anonymised.com> wrote:

Hey,

No it didn’t seem to fix our downstream app: still having that same issue of the metaTileCache bean failing, here is some more output:

18 Sep 15:22:08 INFO [org.geoserver] - Loaded service ‘wms’, enabled
18 Sep 15:22:08 INFO [org.geoserver] - Loaded service ‘wfs’, disabled
18 Sep 15:22:08 INFO [org.geoserver] - Loaded service ‘wcs’, disabled
18 Sep 15:22:09 WARN [support.DisposableBeanAdapter] - Invocation of destroy method failed on bean w
ith name ‘geoServerLoader’: org.springframework.beans.factory.BeanCreationNotAllowedException: Error
creating bean with name ‘metaTileCache’: Singleton bean creation not allowed while the singletons o
f this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method impl
ementation!)
18 Sep 15:22:09 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘wmsGetMap’ d
efined in URL [jar:file:/C:/Users/jhudson/.m2/repository/org/geoserver/wms/2.3-SNAPSHOT/wms-2.3-SNAP
SHOT.jar!/applicationContext.xml]: Cannot resolve reference to bean ‘filterFactory’ while setting be
an property ‘filterFactory’; nested exception is org.springframework.beans.factory.NoSuchBeanDefinit
ionException: No bean named ‘filterFactory’ is defined…

you can see we are not using WFS or WCS, only WMS, but im not even sure where this error begins… Spring somewhere…

Hmm… the filter factory bean I moved from wfs applicationContext to the main application context
because multiple modules were starting to use it.
Was the “main” module rebuilt?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

9

On 18/09/12 16:27, Andrea Aime wrote:

Did not look at the tests, but the first behavior triggers only in cite
compliance mode, so I
guess the test in question is actually running in cite compliance mode,
though I cannot see why
that is happening

Neither can I. The affected test subclasses GeoServerAbstractTestSupport. I do not see anything that turns on CITE compliance. I suspect that there might be something going on in the spring configuration. But why only this test?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

10

On Tue, Sep 18, 2012 at 10:45 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

On 18/09/12 16:27, Andrea Aime wrote:

Did not look at the tests, but the first behavior triggers only in cite
compliance mode, so I
guess the test in question is actually running in cite compliance mode,
though I cannot see why
that is happening

Neither can I. The affected test subclasses GeoServerAbstractTestSupport. I do not see anything that turns on CITE compliance. I suspect that there might be something going on in the spring configuration. But why only this test?

Ha, good question, have no idea, have you tried setting a breakpoint in that portion of the dispatcher and see
what’s going on?
Also put a breakpoint in setCiteCompliant, the dispatcher has to manually be set that way by a
interceptor, normally the CiteComplianceHack class (located in main, and configured as an
interceptor in the url mappings of the service being used)

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

11

On Tue, Sep 18, 2012 at 8:34 AM, John Hudson <johnathon.hudson@anonymised.com> wrote:

18 Sep 15:22:09 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘wmsGetMap’ d
efined in URL [jar:file:/C:/Users/jhudson/.m2/repository/org/geoserver/wms/2.3-SNAPSHOT/wms-2.3-SNAP
SHOT.jar!/applicationContext.xml]: Cannot resolve reference to bean ‘filterFactory’ while setting be
an property ‘filterFactory’; nested exception is org.springframework.beans.factory.NoSuchBeanDefinit
ionException: No bean named ‘filterFactory’ is defined…

you can see we are not using WFS or WCS, only WMS, but im not even sure where this error begins… Spring somewhere…

Ah, locate the issue, when I moved the filterFactory from wfs to main I added it to the
test application context instead of the main one, since all modules run tests depending
on the main test jar the build was unaffected, and things also kept on working fine in
Eclipse, but a separate build would have seen the problem.

Should be fixed now

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

12

Good news everyone, that’s worked for our downstream app.

Thanks again for your time looking into and fixing the issue Andrea and Ben.

Cheers,

John

On Wed, Sep 19, 2012 at 2:10 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Sep 18, 2012 at 8:34 AM, John Hudson <johnathon.hudson@anonymised.com> wrote:

18 Sep 15:22:09 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘wmsGetMap’ d
efined in URL [jar:file:/C:/Users/jhudson/.m2/repository/org/geoserver/wms/2.3-SNAPSHOT/wms-2.3-SNAP
SHOT.jar!/applicationContext.xml]: Cannot resolve reference to bean ‘filterFactory’ while setting be
an property ‘filterFactory’; nested exception is org.springframework.beans.factory.NoSuchBeanDefinit
ionException: No bean named ‘filterFactory’ is defined…

you can see we are not using WFS or WCS, only WMS, but im not even sure where this error begins… Spring somewhere…

Ah, locate the issue, when I moved the filterFactory from wfs to main I added it to the
test application context instead of the main one, since all modules run tests depending
on the main test jar the build was unaffected, and things also kept on working fine in
Eclipse, but a separate build would have seen the problem.

Should be fixed now

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

13

On 18/09/12 16:54, Andrea Aime wrote:

Ha, good question, have no idea, have you tried setting a breakpoint in
that portion of the dispatcher and see
what's going on?
Also put a breakpoint in setCiteCompliant, the dispatcher has to
manually be set that way by a
interceptor, normally the CiteComplianceHack class (located in main, and
configured as an
interceptor in the url mappings of the service being used)

I have found it. Nothing to do with CITE compliance, which is always false. The new code that Andrea added is never entered. It is just a lucky coincidence that this change led me to the workaround.

The cause of the test failure is a change to the bean configuration for propertyName11KvpParser in src/wfs/src/main/java/applicationContext.xml that could have a broad impact on WFS requests that specify propertyName and version without specifying service. I do not know what this change was meant to do, or why it has this effect. I am not even sure what the bean does!

The change was:

commit c03ce370f3a8da0089f3565e3a056f29e63d60d1
Author: alessio <alessio.fabiani@anonymised.com>
Date: Sun Sep 16 18:44:59 2012 +0200
      - CSW: getDomain.propertyName

Removing the change to the bean configuration allows the original PropertySelectionTest to pass.

I also note that the service value is set to "wfs" and not "WFS" as I might have expected.

Here is the diff:

diff --git a/src/wfs/src/main/java/applicationContext.xml b/src/wfs/src/main/java/applicationContext.xml
index b5ad972..42e336d 100644
--- a/src/wfs/src/main/java/applicationContext.xml
+++ b/src/wfs/src/main/java/applicationContext.xml
@@ -348,11 +348,13 @@
      <constructor-arg index="0" value="propertyName"/>
      <constructor-arg index="1" value="java.lang.String"/>
      <property name="version" value="1.0.0"/>
+ <property name="service" value="wfs"/>
    </bean>
    <bean id="propertyName11KvpParser" class="org.geoserver.ows.NestedKvpParser">
          <constructor-arg index="0" value="propertyName"/>
          <constructor-arg index="1" value="java.lang.String"/>
          <property name="version" value="1.1.0"/>
+ <property name="service" value="wfs"/>
      </bean>
    <bean id="maxFeatureKvpParser" class="org.geoserver.ows.util.NumericKvpParser">
      <constructor-arg index="0" value="maxFeatures"/>
@@ -391,6 +393,7 @@
    <bean id="propertyName20KvpParser" class="org.geoserver.wfs.kvp.QNameNestedKvpParser">
      <constructor-arg value="propertyName"/>
      <constructor-arg ref="catalog"/>
+ <property name="service" value="wfs"/>
    </bean>
    <bean id="storedQueryIdKvpParser" class="org.geoserver.wfs.kvp.URIKvpParser">
      <constructor-arg value="storedQueryId"/>

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

14

On Fri, Sep 28, 2012 at 9:40 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

On 18/09/12 16:54, Andrea Aime wrote:

Ha, good question, have no idea, have you tried setting a breakpoint in
that portion of the dispatcher and see
what’s going on?
Also put a breakpoint in setCiteCompliant, the dispatcher has to
manually be set that way by a
interceptor, normally the CiteComplianceHack class (located in main, and
configured as an
interceptor in the url mappings of the service being used)

I have found it. Nothing to do with CITE compliance, which is always false. The new code that Andrea added is never entered. It is just a lucky coincidence that this change led me to the workaround.

The cause of the test failure is a change to the bean configuration for propertyName11KvpParser in src/wfs/src/main/java/applicationContext.xml that could have a broad impact on WFS requests that specify propertyName and version without specifying service. I do not know what this change was meant to do, or why it has this effect. I am not even sure what the bean does!

PropertyName is also a parameter for CSW GetDomain but has an entirely different meaning, and we need a separate
parser for it. The only way to have service specific parsers is to declare the service property on them, making them
activate only when a matching service is specified.

If we don’t want to break backwards compatibility we can have the CSW one declare the service, and the WFS one
not, so that when no service is specified the WFS one triggers anyways

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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