UNCLASSIFIED Hi, I am using GeoServer v2.9.1 running on Java 1.8.0_74 64 bit, Tomcat 7, Centos 7 and I am seeing a null namespace in WFS GetFeature responses when querying a layer that uses a disabled PostGIS datastore (i.e. the underlying PostGIS is available but is disabled in GeoServer). I have a couple of questions regarding this, with further details to follow.
1. Should I be able to make a WFS request to a layer that uses a disabled store and get valid features assuming the underlying store (i.e. PostGIS/PostgreSQL) is actually available? 2. If (1) is true (i.e. I can make a WFS request and get a response with appropriate features when the store is disabled) why is the namespace null for the feature member elements and missing for the feature properties? Is this a bug, due to something I have configured incorrectly, or expected behaviour? The situation is I have a PostGIS datastore running on a separate host from GeoServer, and if the PostGIS store is disabled in GeoServer but actually up and available I can make a WFS GetFeature request and get a response with valid features except that there is a null namespace in the response for each feature member element and the feature properties. This situation came about because we had restarted both the GeoServer and PostGIS hosts and GeoServer had restarted before PostGIS and hence marked the store as disabled. However I can recreate the same symptoms simply by disabling the PostGIS store and then sending the WFS request for the layer. Re-enabling the PostGIS store and sending the WFS request again then results in the "correct" response with the expected namespace. We initially didn't notice the disabled PostGIS store but could still make WFS requests and get features back except that our client was expecting the "normal" namespace (i.e. agiist) and not the "null" namespace and hence complained. A snippet of the WFS response with the null namespace (i.e. made while the PostGIS store is disabled) is as follows: <?xml version="1.0" encoding="UTF-8"?> <wfs:FeatureCollection xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:serval="http://xyz"; xmlns:wfs="http://www.opengis.net/wfs"; xmlns:gml="http://www.opengis.net/gml"; xmlns:ogc="http://www.opengis.net/ogc"; xmlns:ows="http://www.opengis.net/ows"; xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; numberOfFeatures="40" timeStamp="2016-08-25T23:40:35.720Z" xsi:schemaLocation="http://www.opengis.net/wfs http://xyzhost:80/geoserver/schemas/wfs/1.1.0/wfs.xsd http://xyz/agiist http://xyzhost:80/geoserver/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=agiist%3Agazetteer_geonames";> <gml:boundedBy> ... </gml:boundedBy> <gml:featureMembers> <null:gazetteer_geonames xmlns:null="http://xyz/agiist"; gml:id="gazetteer_geonames.fid--405349f1_156b66476cd_-6384"> <gml:name>Blaha (historical)</gml:name> <gml:boundedBy> ... </gml:boundedBy> <asciiname xmlns="http://xyz/agiist";>Blaha (historical)</asciiname> <latitude xmlns="http://xyz/agiist";>43.08333</latitude> <longitude xmlns="http://xyz/agiist";>-97.78333</longitude> <country_code xmlns="http://xyz/agiist";>US</country_code> ... </null:gazetteer_geonames> ... </gml:featureMembers> </wfs:FeatureCollection> A snippet of the "correct" WFS response (i.e. made while the PostGIS store is enabled) is as follows: <?xml version="1.0" encoding="UTF-8"?> <wfs:FeatureCollection xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:serval="http://xyz"; xmlns:wfs="http://www.opengis.net/wfs"; xmlns:agiist="http://xyz/agiist"; xmlns:gml="http://www.opengis.net/gml"; xmlns:ogc="http://www.opengis.net/ogc"; xmlns:ows="http://www.opengis.net/ows"; xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; numberOfFeatures="40" timeStamp="2016-08-25T07:15:06.500Z" xsi:schemaLocation="http://www.opengis.net/wfs http://xyzhost:80/geoserver/schemas/wfs/1.1.0/wfs.xsd http://xyz/agiist http://xyzhost:80/geoserver/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=agiist%3Agazetteer_geonames";> <gml:boundedBy> ... </gml:boundedBy> <gml:featureMembers> <agiist:gazetteer_geonames gml:id="gazetteer_geonames.fid--405349f1_156b66476cd_-69dc"> <gml:name>Blaha (historical)</gml:name> <gml:boundedBy> ... </gml:boundedBy> <agiist:asciiname>Blaha (historical)</agiist:asciiname> <agiist:latitude>43.08333</agiist:latitude> <agiist:longitude>-97.78333</agiist:longitude> <agiist:country_code>US</agiist:country_code> ... </agiist:gazetteer_geonames> ... </gml:featureMembers> </wfs:FeatureCollection> Finally, if all of this is expected behaviour then can GeoServer automatically re-enable a store if it becomes available or is it simply up to a GeoServer administrator to manually go in and re-enable it? It would be nice for GeoServer to be tolerant of a PostGIS store potentially being unavailable or dropping out and then becoming available/online. Regards, Steve Johnson IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.
------------------------------------------------------------------------------
_______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
