[Geoserver-devel] Null attributes, issues trying to write a formal test

GeoServer GeoServer Developer
1

Hi,
so I went ahead and prototyped a bit the idea of using xsd:nil=“true” to mark null
elements, the results given back by GeoServer with the modified feature transformer
validate fine in Eclipse, here is a sample from the “nulls” dataset used for CITE tests:

<?xml version="1.0" encoding="UTF-8"?>

<wfs:FeatureCollection xmlns=“http://www.opengis.net/wfs”
xmlns:wfs=“http://www.opengis.net/wfs” xmlns:it.geosolutions=“http://www.geo-solutions.it”
xmlns:gml=“http://www.opengis.net/gml” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd http://www.geo-solutions.it http://localhost:8080/geoserver/it.geosolutions/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=it.geosolutions%3ANulls”>
gml:boundedBy
gml:nullunknown</gml:null>
</gml:boundedBy>
gml:featureMember
<it.geosolutions:Nulls fid=“Nulls.0”>
it.geosolutions:descriptionnullFeature </it.geosolutions:description>
it.geosolutions:name
</it.geosolutions:name>
it.geosolutions:boundedBy
<gml:Polygon srsName=“http://www.opengis.net/gml/srs/epsg.xml#32615”>
gml:outerBoundaryIs
gml:LinearRing
<gml:coordinates xmlns:gml=“http://www.opengis.net/gml”
decimal=“.” cs=“,” ts=" ">500000,500000 500000,500100 500100,500100
500100,500000 500000,500000</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</it.geosolutions:boundedBy>
<it.geosolutions:integers xsi:nil=“true” />
<it.geosolutions:dates xsi:nil=“true” />
<it.geosolutions:pointProperty xsi:nil=“true” />
</it.geosolutions:Nulls>
</gml:featureMember>
</wfs:FeatureCollection>

However I wanted to have a validation test also in the build and tried something as follows, using
the Parser in validating mode:

/**

  • Validates a document against the
  • @param dom
  • @param configuration
    */
    protected void checkValidationErrors(Document dom, Configuration configuration) throws Exception {
    Parser p = new Parser(configuration);
    p.setValidating( true );
    p.parse( new DOMSource( dom ) );

if ( !p.getValidationErrors().isEmpty() ) {
for ( Iterator e = p.getValidationErrors().iterator(); e.hasNext(); ) {
SAXParseException ex = (SAXParseException) e.next();
System.out.println( ex.getLineNumber() + “,” + ex.getColumnNumber() + " -" + ex.toString() );
}
fail( “Document did not validate.”);
}
}

public void testNullValues() throws Exception {
Document doc = getAsDOM(“/wfs?request=GetFeature&typename=” + getLayerId(MockData.NULLS) + “&version=1.0.0&service=wfs”);
print(doc);
checkValidationErrors(doc, (Configuration) applicationContext.getBean(“xmlConfiguration-1.0”));
}

Unfortunately that breaks when it finds the back reference to DescribeFeatureType cannot be resolved
(because GeoServer is not really running). Do you know if there is any workaround for that?
I thought that maybe I can try to modify the DOM and have the schema location point to a local file
with the schema… seems a bit rough though, any better idea?

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

2

On Thu, Aug 23, 2012 at 3:35 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

However I wanted to have a validation test also in the build and tried something as follows, using
the Parser in validating mode:

/**

  • Validates a document against the
  • @param dom
  • @param configuration
    */
    protected void checkValidationErrors(Document dom, Configuration configuration) throws Exception {
    Parser p = new Parser(configuration);
    p.setValidating( true );
    p.parse( new DOMSource( dom ) );

if ( !p.getValidationErrors().isEmpty() ) {
for ( Iterator e = p.getValidationErrors().iterator(); e.hasNext(); ) {
SAXParseException ex = (SAXParseException) e.next();
System.out.println( ex.getLineNumber() + “,” + ex.getColumnNumber() + " -" + ex.toString() );
}
fail( “Document did not validate.”);
}
}

public void testNullValues() throws Exception {
Document doc = getAsDOM(“/wfs?request=GetFeature&typename=” + getLayerId(MockData.NULLS) + “&version=1.0.0&service=wfs”);
print(doc);
checkValidationErrors(doc, (Configuration) applicationContext.getBean(“xmlConfiguration-1.0”));
}

Unfortunately that breaks when it finds the back reference to DescribeFeatureType cannot be resolved
(because GeoServer is not really running). Do you know if there is any workaround for that?
I thought that maybe I can try to modify the DOM and have the schema location point to a local file
with the schema… seems a bit rough though, any better idea?

Anyone? I guess the rough idea is not that rough anyways :-p

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

3

Yeah, in the past i have done just this. Have the pre-canned DFT response sitting alongside the test case, and then copy it out into temp and change the reference in the xml file to point to it. Can’t remember exactly where that was… i will try to look for it.

Another possibility would be to place a custom schema locator or location resolver into the context. Those interfaces are used just for purposes such as this.

On Fri, Aug 24, 2012 at 7:32 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Aug 23, 2012 at 3:35 PM, Andrea Aime <andrea.aime@anonymised.com1268…> wrote:

However I wanted to have a validation test also in the build and tried something as follows, using
the Parser in validating mode:

/**

  • Validates a document against the
  • @param dom
  • @param configuration
    */
    protected void checkValidationErrors(Document dom, Configuration configuration) throws Exception {
    Parser p = new Parser(configuration);
    p.setValidating( true );
    p.parse( new DOMSource( dom ) );

if ( !p.getValidationErrors().isEmpty() ) {
for ( Iterator e = p.getValidationErrors().iterator(); e.hasNext(); ) {
SAXParseException ex = (SAXParseException) e.next();
System.out.println( ex.getLineNumber() + “,” + ex.getColumnNumber() + " -" + ex.toString() );
}
fail( “Document did not validate.”);
}
}

public void testNullValues() throws Exception {
Document doc = getAsDOM(“/wfs?request=GetFeature&typename=” + getLayerId(MockData.NULLS) + “&version=1.0.0&service=wfs”);
print(doc);
checkValidationErrors(doc, (Configuration) applicationContext.getBean(“xmlConfiguration-1.0”));
}

Unfortunately that breaks when it finds the back reference to DescribeFeatureType cannot be resolved
(because GeoServer is not really running). Do you know if there is any workaround for that?
I thought that maybe I can try to modify the DOM and have the schema location point to a local file
with the schema… seems a bit rough though, any better idea?

Anyone? I guess the rough idea is not that rough anyways :-p

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

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

On Fri, Aug 24, 2012 at 5:05 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, in the past i have done just this. Have the pre-canned DFT response sitting alongside the test case, and then copy it out into temp and change the reference in the xml file to point to it. Can’t remember exactly where that was… i will try to look for it.

Another possibility would be to place a custom schema locator or location resolver into the context. Those interfaces are used just for purposes such as this.

Followed your suggestion and yes, it works fine, the validation passes once Parser learns how to handle xsi:nil,
for which I have a patch here:

http://jira.codehaus.org/browse/GEOT-4244

I guess the encoder will need a similar one?

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

5

On Fri, Aug 24, 2012 at 10:04 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Aug 24, 2012 at 5:05 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, in the past i have done just this. Have the pre-canned DFT response sitting alongside the test case, and then copy it out into temp and change the reference in the xml file to point to it. Can’t remember exactly where that was… i will try to look for it.

Another possibility would be to place a custom schema locator or location resolver into the context. Those interfaces are used just for purposes such as this.

Followed your suggestion and yes, it works fine, the validation passes once Parser learns how to handle xsi:nil,
for which I have a patch here:

http://jira.codehaus.org/browse/GEOT-4244

I guess the encoder will need a similar one?

Nice. Patch looks good. Indeed the next natural step would be update the encoder which I don’t think will be too difficult but probably something we want to add an encoding option for as it will change the way we output gml.

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

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.