Justin,
many CITE tests look broken on Jenkins. Any idea what is wrong? Some have been broken for over two weeks.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
On Wed, Apr 30, 2014 at 5:35 AM, Ben Caradoc-Davies <
Ben.Caradoc-Davies@anonymised.com> wrote:
Justin,
many CITE tests look broken on Jenkins. Any idea what is wrong? Some
have been broken for over two weeks.
Broken solid? What I see is that the test are failing every other day, see
for example:
http://ares.boundlessgeo.com/jenkins/job/2.5-cite-wfs-1.0/
Last time I looked at a similar situation I could not reproduce locally and
assumed
it was somehow environmental to the build server, but of course I may be
wrong
and it's maybe luck of the draw (race condition of sorts)
Cheers
Andrea
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
-------------------------------------------------------
Some have been broken for 17 days. Is that solid?
http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/
Kind regards,
Ben.
On 30/04/14 16:09, Andrea Aime wrote:
On Wed, Apr 30, 2014 at 5:35 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com <mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:Justin,
many CITE tests look broken on Jenkins. Any idea what is wrong? Some
have been broken for over two weeks.Broken solid? What I see is that the test are failing every other day,
see for example:
http://ares.boundlessgeo.com/jenkins/job/2.5-cite-wfs-1.0/Last time I looked at a similar situation I could not reproduce locally
and assumed
it was somehow environmental to the build server, but of course I may be
wrong
and it's maybe luck of the draw (race condition of sorts)Cheers
Andrea--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.Ing. Andrea Aime
@geowolf
Technical LeadGeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549http://www.geo-solutions.it
http://twitter.com/geosolutions_it-------------------------------------------------------
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
On Wed, Apr 30, 2014 at 10:33 AM, Ben Caradoc-Davies <
Ben.Caradoc-Davies@anonymised.com> wrote:
Some have been broken for 17 days. Is that solid?
http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/
Oh yes, this one looks pretty solid to me :-p
Cheers
Andrea
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
-------------------------------------------------------
On 30/04/14 16:38, Andrea Aime wrote:
Oh yes, this one looks pretty solid to me :-p
But your observation is a good one. We could two types of failures, both intermittent ones caused by problems on the build platform, and harder failures caused by code changes that the tests are meant to catch.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
@Ben: Unfortunately i haven’t time to investigate further due to being swamped with project work. If someone has some spare cycles and could run all the tests locally that would help, as that is my next step.
But I did do a bit of investigation when things started breaking, here is what I found. I manage to fix a couple of the tests on master because they were still running with a version 6 jdk. I rebooted and reran all the other tests and from what I could tell there were what appeared to be some legitimate failures. For example, for WCS 1.0 to pass some of the tests that require we throw exception on capabilities requests we have to remove all the other wcs modules. That hack didn’t seem to be working.
So… sorry, but i a not sure when I am going to be able to spend more time on this. Most likely not this week. If people prefer, I can shut down notifications from those jobs.
On Wed, Apr 30, 2014 at 2:40 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:
On 30/04/14 16:38, Andrea Aime wrote:
Oh yes, this one looks pretty solid to me :-p
But your observation is a good one. We could two types of failures, both intermittent ones caused by problems on the build platform, and harder failures caused by code changes that the tests are meant to catch.
Kind regards,
–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
On Wed, Apr 30, 2014 at 3:56 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
@Ben: Unfortunately i haven't time to investigate further due to being
swamped with project work. If someone has some spare cycles and could run
all the tests locally that would help, as that is my next step.
Hi Justin,
I've just run the WFS 1.1 cite tests on geoserver master, using postgis 2
as the backend (that's what I have),
loading the database using dataset-sf0-postgis2.sql (for which I had to
make a small fix to one of the geometry columns declarations).
GeoServer was started from Eclipse.
And... I get a full pass, 568 tests passing, including those that fail on
the build server for the past weeks (
http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/)
I'll have a look and see if I can stand up postgis 1.x anywhere, maybe it's
related to the
postgis/postgresql version... although... it seems unlikely, one test is
doing a simple equality check
against a string attribute, the other two should be failing because of a
validation error in the
query and instead they are returning a FeatureCollection... it's as if the
strict compliance checks
are not enabled anymore?
I've checked the build server, the cite compliance flag is up... so not
sure what's going on there (besides, those
two should not be the only tests where strict cite compliance
http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/ws/geoserver_data/master/citewfs-1.1/wfs.xml
But I did do a bit of investigation when things started breaking, here is
what I found. I manage to fix a couple of the tests on master because they
were still running with a version 6 jdk. I rebooted and reran all the other
tests and from what I could tell there were what appeared to be some
legitimate failures. For example, for WCS 1.0 to pass some of the tests
that require we throw exception on capabilities requests we have to remove
all the other wcs modules. That hack didn't seem to be working.
Going to check this one too.
Cheers
Andrea
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
-------------------------------------------------------
On Thu, May 1, 2014 at 10:15 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
And... I get a full pass, 568 tests passing, including those that fail on
the build server for the past weeks (
http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/
)
I'll have a look and see if I can stand up postgis 1.x anywhere, maybe
it's related to the
postgis/postgresql version... although... it seems unlikely, one test is
doing a simple equality check
against a string attribute, the other two should be failing because of a
validation error in the
query and instead they are returning a FeatureCollection... it's as if the
strict compliance checks
are not enabled anymore?
Hi,
so I've downloaded the nightly build and run that one instead, and while I
cannot reproduce the GetFeature-tc5.3
failure, the other two are there.
I've attached a debugger, stepped though the code, the parser is put in
validating mode, yet it's not complaining
about the wfs:Smuery element.
Made some further investigation, one first thing that is striking me is
that the WFS xml parsing sets
the parser in validating mode, but not in strict mode, when the cite
compliance hack is enabled.
The WCS/CSW xml parsers are instead put in strict mode too when the the
compliance hacks are enabled.
I've then compared to what happens when running GeoServer from Eclipse, and
found the difference
is that the SAX parser emits an error caught by
ParserHandler.error(SAXParseException) when working
in Eclipse, but not when running the stand alone binary package.
Checking what SAX parser gets instantiated I've found:
* Running from
Eclipse: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl@anonymised.com(JDK
own parser)
* Running from bin package
(Jetty): org.apache.xerces.jaxp.SAXParserFactoryImpl@anonymised.com (Eeek...
Xerces stand alone!)
Looking in the bin package:
find . -name "*xerces*"
./lib/xercesImpl-2.7.1.jar <--- It's in Jetty!!
Now, in recent version of Java this might not be required anymore right? So
I've moved it out and restarted
the package, it started fine, rerun the cite tests and (drumroll)... full
pass!
There are still two bits outstanding:
* no idea why this started happening only some time ago (java version
changes in the server maybe?)
* the GetFeature-tc5.3 failiure is still non reproducable for me
About the xerces dependency... shall we try removing it from the bin
package? I believe it was there
for Jetty, but if GeoServer starts, I guess the Jetty code was already
using JAXP to find the xml
parsers and it's probably picking up the JDK ones now.
Cheers
Andrea
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
-------------------------------------------------------
On Wed, Apr 30, 2014 at 3:56 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
@Ben: Unfortunately i haven't time to investigate further due to being
swamped with project work. If someone has some spare cycles and could run
all the tests locally that would help, as that is my next step.But I did do a bit of investigation when things started breaking, here is
what I found. I manage to fix a couple of the tests on master because they
were still running with a version 6 jdk. I rebooted and reran all the other
tests and from what I could tell there were what appeared to be some
legitimate failures. For example, for WCS 1.0 to pass some of the tests
that require we throw exception on capabilities requests we have to remove
all the other wcs modules. That hack didn't seem to be working.
I've just tried WCS 1.0 tests, this time using the same bin package used
for WFS (with xerces removed from the picture),
and as you said I've removed the gs-wcs1_1 and gs-wcs2_0 jars from the
picture in order to avoid issues with the
wcs 1.0 caps cite tests (which are assuming the server does not implement
higher versions of the protocol).
I have a full pass, 114 tests passing.
I'm wondering:
- where is the code that's removing the higher versions of the wcs jars
from the geoserver war? I don't see it in run.sh
- maybe the issue is caused by wcs 2.0 graduating to supported status, and
the 2.0 jar not being removed before running the tests?
The WCS 1.1 tests are instead at least partly because wcs 2.0 is now in the
classpath, going to have a look at it there
are class cast exceptions when running:
Caused by: java.lang.ClassCastException:
net.opengis.ows11.impl.SectionsTypeImpl cannot be cast to
net.opengis.ows20.SectionsType
at
net.opengis.ows20.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:409)
at
net.opengis.wcs20.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:148)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:1081)
I guess that in this case the version negotiation is not probably handled
at the dispatcher level, since accept_versions is set
it should try to parse the request as a 1.1.1 one, not as a 2.0 one.
Just to see if there is anything else, I've removed the WCS 2.0 jar from
GeoServer and re-run the CITE tests, getting a full pass.
Cheers
Andrea
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
-------------------------------------------------------
Thanks for helping out with this Andrea.
The xerces dependency from Jetty makes sense. And I guess this one just laid dormant while we ran on java 6. Perhaps the switch did trigger something.
Anyways, I think it’s worth a shot to try removing it.
On Thu, May 1, 2014 at 2:54 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
On Thu, May 1, 2014 at 10:15 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
so I’ve downloaded the nightly build and run that one instead, and while I cannot reproduce the GetFeature-tc5.3
failure, the other two are there.
I’ve attached a debugger, stepped though the code, the parser is put in validating mode, yet it’s not complaining
about the wfs:Smuery element.
Made some further investigation, one first thing that is striking me is that the WFS xml parsing sets
the parser in validating mode, but not in strict mode, when the cite compliance hack is enabled.
The WCS/CSW xml parsers are instead put in strict mode too when the the compliance hacks are enabled.
I’ve then compared to what happens when running GeoServer from Eclipse, and found the difference
is that the SAX parser emits an error caught by ParserHandler.error(SAXParseException) when working
in Eclipse, but not when running the stand alone binary package.
Checking what SAX parser gets instantiated I’ve found:
Looking in the bin package:
find . -name “xerces”
./lib/xercesImpl-2.7.1.jar <— It’s in Jetty!!
Now, in recent version of Java this might not be required anymore right? So I’ve moved it out and restarted
the package, it started fine, rerun the cite tests and (drumroll)… full pass!
There are still two bits outstanding:
About the xerces dependency… shall we try removing it from the bin package? I believe it was there
for Jetty, but if GeoServer starts, I guess the Jetty code was already using JAXP to find the xml
parsers and it’s probably picking up the JDK ones now.
Cheers
Andrea
–
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
And… I get a full pass, 568 tests passing, including those that fail on the build server for the past weeks (http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/)
I’ll have a look and see if I can stand up postgis 1.x anywhere, maybe it’s related to the
postgis/postgresql version… although… it seems unlikely, one test is doing a simple equality check
against a string attribute, the other two should be failing because of a validation error in the
query and instead they are returning a FeatureCollection… it’s as if the strict compliance checks
are not enabled anymore?
On Thu, May 1, 2014 at 3:15 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:
On Wed, Apr 30, 2014 at 3:56 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:@Ben: Unfortunately i haven't time to investigate further due to being
swamped with project work. If someone has some spare cycles and could run
all the tests locally that would help, as that is my next step.But I did do a bit of investigation when things started breaking, here is
what I found. I manage to fix a couple of the tests on master because they
were still running with a version 6 jdk. I rebooted and reran all the other
tests and from what I could tell there were what appeared to be some
legitimate failures. For example, for WCS 1.0 to pass some of the tests
that require we throw exception on capabilities requests we have to remove
all the other wcs modules. That hack didn't seem to be working.I've just tried WCS 1.0 tests, this time using the same bin package used
for WFS (with xerces removed from the picture),
and as you said I've removed the gs-wcs1_1 and gs-wcs2_0 jars from the
picture in order to avoid issues with the
wcs 1.0 caps cite tests (which are assuming the server does not implement
higher versions of the protocol).I have a full pass, 114 tests passing.
I'm wondering:
- where is the code that's removing the higher versions of the wcs jars
from the geoserver war? I don't see it in run.sh
It is in the individual data directories.
https://github.com/geoserver/geoserver/blob/master/data/citewcs-1.0/init.sh
https://github.com/geoserver/geoserver/blob/master/data/citewcs-1.1/init.sh
run.sh calls those scripts if they exist around line 56.
- maybe the issue is caused by wcs 2.0 graduating to supported status, and
the 2.0 jar not being removed before running the tests?
Makes sense... although it seems like those regex should remove it. I just
did a wcs 1.0 run and checked the contents of the WEB-INF/lib directory.
jenkins@anonymised.com:~/cite/geoserver/geoserver-2.6-SNAPSHOT/webapps/geoserver/WEB-INF/lib$
ls | grep wcs
gs-wcs1_0-2.6-SNAPSHOT.jar
gs-wcs-2.6-SNAPSHOT.jar
gt-xsd-wcs-12-SNAPSHOT.jar
net.opengis.wcs-12-SNAPSHOT.jar
And it looks like the right jars are removed... unless its something in the
common jar that now leads to the conflict?
The WCS 1.1 tests are instead at least partly because wcs 2.0 is now in
the classpath, going to have a look at it there
are class cast exceptions when running:Caused by: java.lang.ClassCastException:
net.opengis.ows11.impl.SectionsTypeImpl cannot be cast to
net.opengis.ows20.SectionsType
at
net.opengis.ows20.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:409)
at
net.opengis.wcs20.impl.GetCapabilitiesTypeImpl.eSet(GetCapabilitiesTypeImpl.java:148)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:1081)I guess that in this case the version negotiation is not probably handled
at the dispatcher level, since accept_versions is set
it should try to parse the request as a 1.1.1 one, not as a 2.0 one.Just to see if there is anything else, I've removed the WCS 2.0 jar from
GeoServer and re-run the CITE tests, getting a full pass.Cheers
Andrea--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.Ing. Andrea Aime
@geowolf
Technical LeadGeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549http://www.geo-solutions.it
http://twitter.com/geosolutions_it-------------------------------------------------------
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive>
On Thu, May 1, 2014 at 2:50 PM, Justin Deoliveira <jdeolive@anonymised.com
wrote:
Thanks for helping out with this Andrea.
The xerces dependency from Jetty makes sense. And I guess this one just
laid dormant while we ran on java 6. Perhaps the switch did trigger
something.Anyways, I think it's worth a shot to try removing it.
Done that, we're doing to a single failure:
[exec] Test wfs:wfs-main (wfs-1.1.0) Failed (Inherited Failure)
[exec] Test wfs:readiness-tests (wfs-1.1.0/d41e34700_1) Failed
(Inherited Failure)
[exec] Test wfs:basic-main
(wfs-1.1.0/d41e34700_1/d41e749_1) Failed (Inherited Failure)
[exec] Test wfs:run-GetFeature-POST
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1) Failed (Inherited
Failure)
[exec] Test wfs:wfs-1.1.0-Basic-GetFeature-tc5.3
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1) Failed
(Inherited Failure)
[exec] Test ctl:assert-xpath
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1/d41e16520_1)
Failed
[exec] Test ctl:assert-xpath
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1/d41e16530_1)
Failed
However... I cannot reproduce this one locally, not sure what might be
causing it. The logs are not that useful:
[exec] Testing wfs:wfs-1.1.0-Basic-GetFeature-tc5.3
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1)...
[exec] Assertion: The response entity must be
schema valid and include any optional feature properties requested by
the client. The document element must be a wfs:FeatureCollection.
[exec] Testing ctl:assert-xpath
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1/d41e16520_1)...
[exec] Assertion:
[exec] Evaluates the given XPath expression against the
input document and
[exec] returns a boolean result according to the XPath
specification (see
[exec] http://www.w3.org/TR/xpath#section-Boolean-Functions).
[exec]
[exec] The expression
'//wfs:FeatureCollection' is false.
[exec] Test ctl:assert-xpath Failed
[exec] Testing ctl:assert-xpath
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1/d41e16530_1)...
[exec] Assertion:
[exec] Evaluates the given XPath expression against the
input document and
[exec] returns a boolean result according to the XPath
specification (see
[exec] http://www.w3.org/TR/xpath#section-Boolean-Functions).
[exec]
[exec] The expression '//sf:measurand' is false.
[exec] Test ctl:assert-xpath Failed
[exec] Testing ctl:assert-xpath
(wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1/d41e16541_1)...
[exec] Assertion:
[exec] Evaluates the given XPath expression against the
input document and
[exec] returns a boolean result according to the XPath
specification (see
[exec] http://www.w3.org/TR/xpath#section-Boolean-Functions).
[exec]
[exec] Test ctl:assert-xpath Passed
[exec] Test wfs:wfs-1.1.0-Basic-GetFeature-tc5.3
Failed (Inherited failure)
From what I can see, GeoServer is not returning a feature collection when
that request is run, when running locally (where it
works) the logs from the CITE engine web UI look like:
<wfs:GetFeature xmlns="http://www.occamlab.com/ctl"
xmlns:ctl="http://www.occamlab.com/ctl"
xmlns:gml="http://www.opengis.net/gml"
xmlns:myparsers="http://teamengine.sourceforge.net/parsers"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:ows="http://www.opengis.net/ows"
xmlns:p="http://teamengine.sourceforge.net/parsers"
xmlns:parsers="http://www.occamlab.com/te/parsers"
xmlns:saxon="http://saxon.sf.net/"
xmlns:sf="http://cite.opengeospatial.org/gmlsf"
xmlns:te="http://www.occamlab.com/te"
xmlns:tec="java:com.occamlab.te.TECore"
xmlns:tems="java:com.occamlab.te.web.MonitorServlet"
xmlns:wfs="http://www.opengis.net/wfs"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
service="WFS"
version="1.1.0">
<wfs:Query srsName="urn:ogc:def:crs:EPSG::4326"
typeName="sf:PrimitiveGeoFeature">
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>sf:intProperty</ogc:PropertyName>
<ogc:Literal>300</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>
Response from parser p:XMLValidatingParser.GMLSF1:
<wfs:FeatureCollection xmlns:gml="http://www.opengis.net/gml"
xmlns:it.geosolutions="http://www.geo-solutions.it"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:ows="http://www.opengis.net/ows"
xmlns:sf="http://cite.opengeospatial.org/gmlsf"
xmlns:wfs="http://www.opengis.net/wfs"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
numberOfFeatures="1"
timeStamp="2014-05-01T08:50:15.799Z"
xsi:schemaLocation="http://cite.opengeospatial.org/gmlsf
http://localhost:8080/geoserver/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=sf%3APrimitiveGeoFeature
http://www.opengis.net/wfs
http://localhost:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd">
<gml:boundedBy>
<gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">
<gml:lowerCorner>45.174 30.466</gml:lowerCorner>
<gml:upperCorner>45.891 30.899</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<gml:featureMembers>
<sf:PrimitiveGeoFeature gml:id="PrimitiveGeoFeature.f008">
<gml:description>description-f008</gml:description>
<gml:name>name-f008</gml:name>
<gml:boundedBy>
<gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">
<gml:lowerCorner>45.174 30.466</gml:lowerCorner>
<gml:upperCorner>45.891 30.899</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<sf:surfaceProperty>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:posList>45.174 30.899 45.652 30.466 45.891
30.466 45.174 30.899</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</sf:surfaceProperty>
<sf:intProperty>300</sf:intProperty>
<sf:measurand>783.5</sf:measurand>
<sf:dateTimeProperty>2006-06-28T05:08:00Z</sf:dateTimeProperty>
<sf:dateProperty>2006-12-12Z</sf:dateProperty>
<sf:decimalProperty>18.92</sf:decimalProperty>
</sf:PrimitiveGeoFeature>
</gml:featureMembers>
What can make a simple equality test ("intProperty" = 300) fail on the
build server? And why only this one.
We should probably run the test again and see in the GeoServer logs, maybe
we'll find an exception in there.
Time out for me, maybe I'll have a look again during the weekend.
Cheers
Andrea
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
-------------------------------------------------------
On Fri, May 2, 2014 at 11:04 PM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
What can make a simple equality test ("intProperty" = 300) fail on the
build server? And why only this one.
We should probably run the test again and see in the GeoServer logs, maybe
we'll find an exception in there.
Time out for me, maybe I'll have a look again during the weekend.
And so I did, and the build succeeded:
http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/200/
and then I ran it again, this time it failed:
http://ares.boundlessgeo.com/jenkins/job/cite-wfs-1.1/201/console
However in the GeoServer logs there is nothing, like, it seems the request
did not actually fail
according to GeoServer:
2014-05-03 06:15:43,620 INFO [geoserver.wfs] -
Request: getFeature
service = WFS
version = 1.1.0
baseUrl = http://localhost:11010/geoserver/
query[0]:
* filter = [ sf:intProperty = 300 ]*
srsName = urn:ogc:def:crs:EPSG::4326
typeName[0] = {http://cite.opengeospatial.org/gmlsf\}PrimitiveGeoFeature
outputFormat = text/xml; subtype=gml/3.1.1
resultType = results
2014-05-03 06:15:43,706 INFO [geoserver.wfs] -
Request: getServiceInfo
...
2014-05-03 06:15:43,798 INFO [geoserver.wfs] -
Request: getFeature
service = WFS
version = 1.1.0
baseUrl = http://localhost:11010/geoserver/
query[0]:
filter = [ sf:boolProperty = 1 ]
srsName = urn:ogc:def:crs:EPSG::4326
typeName[0] = {http://cite.opengeospatial.org/gmlsf\}EntitéGénérique
outputFormat = text/xml; subtype=gml/3.1.1
resultType = results
2014-05-03 06:15:43,922 INFO [geoserver.wfs] -
I've then been looking at the cite test run logs, and there we have
something:
<log>
<starttest local-name="assert-xpath" prefix="ctl" namespace-uri="
http://www.occamlab.com/ctl" path="
wfs-1.1.0/d41e34700_1/d41e749_1/d41e24772_1/d41e15477_1/d41e16520_1" file="
/var/lib/jenkins/workspace/geoserver-cite/tools/target/work/~2Fvar~2Flib~2Fjenkins~2Fworkspace~2Fgeoserver-cite~2Ftools~2Fengine~2Fscripts~2Fwfs-1.1.0~2Fctl~2Fall.xml/ctl$assert-xpath.test
">
<assertion>
Evaluates the given XPath expression against the input document and returns
a boolean result according to the XPath specification (see
http://www.w3.org/TR/xpath#section-Boolean-Functions).
</assertion>
<params xmlns:tems="java:com.occamlab.te.web.MonitorServlet" xmlns:gml="
http://www.opengis.net/gml" xmlns:saxon="http://saxon.sf.net/" xmlns:ogc="
http://www.opengis.net/ogc" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="
http://www.w3.org/1999/xlink" xmlns:parsers="
http://www.occamlab.com/te/parsers" xmlns:ctl="http://www.occamlab.com/ctl"
xmlns:te="http://www.occamlab.com/te"xmlns:xsd="
http://www.w3.org/2001/XMLSchema" xmlns:p="
http://teamengine.sourceforge.net/parsers" xmlns:xi="
http://www.w3.org/2001/XInclude" xmlns:sf="
http://cite.opengeospatial.org/gmlsf" xmlns:wfs="http://www.opengis.net/wfs"
xmlns:myparsers="http://teamengine.sourceforge.net/parsers" xmlns:ows="
http://www.opengis.net/ows" xmlns:tec="java:com.occamlab.te.TECore">
<param local-name="expr" namespace-uri="" prefix="" type="document-node()">
<value>//wfs:FeatureCollection</value>
</param>
<param local-name="doc" namespace-uri="" prefix="" type="
document-node(element({http://www.opengis.net/ows\}ExceptionReport,
xs:anyType))">
<value>
<ows:ExceptionReport version="1.0.0" xsi:schemaLocation="
http://www.opengis.net/ows
http://localhost:11010/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd">
<ows:Exception exceptionCode="NoApplicableCode">
<ows:ExceptionText>
java.lang.RuntimeException: java.io.IOException java.io.IOException null An
I/O error occured while sending to the backend. Stream closed
</ows:ExceptionText>
</ows:Exception>
<!-- Response received in [219] milliseconds -->
</ows:ExceptionReport>
</value>
</param>
</params>
</starttest>
<message id="d41e28_1">
<![CDATA[ The expression '//wfs:FeatureCollection' is false. ]]>
</message>
<endtest result="3"/>
</log>
Hmm.. why is that not visible in the GeoServer logs I wonder?
By the looks of it, it seems the postgis connection is lost? I've just
committed a change to enable
connection validation in the store, let's see if this fixes the problem.
Cheers
Andrea
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
-------------------------------------------------------
On Sat, May 3, 2014 at 8:48 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:
Hmm.. why is that not visible in the GeoServer logs I wonder?
By the looks of it, it seems the postgis connection is lost? I've just
committed a change to enable
connection validation in the store, let's see if this fixes the problem.
So I've added a connection validation flag to the store:
https://github.com/geoserver/geoserver/blob/master/data/citewfs-1.1/workspaces/sf/sf/datastore.xml
However the build server did not pick it up... how does one force the data
dirs to update?
http://ares.boundlessgeo.com/jenkins/view/geoserver-cite/job/cite-wfs-1.1/ws/geoserver_data/master/citewfs-1.1/workspaces/sf/sf/datastore.xml
Looking at the scripts I don't see anything doing a git pull, and the build
itself does not have a version control
enabled (understandable, that directory layout does not come from the
GeoServer sources nor the CITE tests ones).
Cheers
Andrea
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
-------------------------------------------------------
On Sat, May 3, 2014 at 3:39 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:
On Sat, May 3, 2014 at 8:48 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:
Hmm.. why is that not visible in the GeoServer logs I wonder?
By the looks of it, it seems the postgis connection is lost? I've just
committed a change to enable
connection validation in the store, let's see if this fixes the problem.So I've added a connection validation flag to the store:
https://github.com/geoserver/geoserver/blob/master/data/citewfs-1.1/workspaces/sf/sf/datastore.xml
However the build server did not pick it up... how does one force the data
dirs to update?Looking at the scripts I don't see anything doing a git pull, and the
build itself does not have a version control
enabled (understandable, that directory layout does not come from the
GeoServer sources nor the CITE tests ones).You're right. It was only cleaning out local changes and not grabbing any
updates. Updated run.sh so it should update the data directories now.
Cheers
Andrea--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.Ing. Andrea Aime
@geowolf
Technical LeadGeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549http://www.geo-solutions.it
http://twitter.com/geosolutions_it-------------------------------------------------------
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive>
On Mon, May 12, 2014 at 5:13 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Looking at the scripts I don't see anything doing a git pull, and the
build itself does not have a version control
enabled (understandable, that directory layout does not come from the
GeoServer sources nor the CITE tests ones).You're right. It was only cleaning out local changes and not grabbing any
updates. Updated run.sh so it should update the data directories now.
Excellent, let's see if that helps fixing the residual random failures in
wfs 1.1 (we'll know in a week or so, I guess).
Cheers
Andrea
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
-------------------------------------------------------
On Mon, May 12, 2014 at 10:51 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Mon, May 12, 2014 at 5:13 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:Looking at the scripts I don't see anything doing a git pull, and the
build itself does not have a version control
enabled (understandable, that directory layout does not come from the
GeoServer sources nor the CITE tests ones).You're right. It was only cleaning out local changes and not grabbing
any updates. Updated run.sh so it should update the data directories now.
Excellent, let's see if that helps fixing the residual random failures in
wfs 1.1 (we'll know in a week or so, I guess).Fingers crossed. Also there was another wrench in the works. Recently i
added another build executor to get more build throughput for non
geotools/geoserver projects. Everything geotools/geoserver is throttled so
that only a single job executes at one time. However some of the cite jobs
weren't configured properly so were executing simultaneously. That is fixed
now so hopefully that helps things as well.
Cheers
Andrea--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.Ing. Andrea Aime
@geowolf
Technical LeadGeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549http://www.geo-solutions.it
http://twitter.com/geosolutions_it-------------------------------------------------------
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive>