3

I just tested what I thought to be a very basic PostgreSQL -> GeoServer WFS-t -> QGIS setup that strangely issues an error.

I have a server on which I installed a PostgreSQL+PostGIS instance (featuring a point table) and a GeoServer instance. I set GeoServer to serve the postgis table as WFS-t, but requiring login to view and edit. Using the wfs link of GeoServer (http://XXX/geoserver/wfs) I loaded the layer in QGIS. Doing so without any login info, I can't see the layer as expected. When I load the WFS layer in QGIS with the correct login info, I'm able to view it, but when I want to save edit's I get the following error in QGIS:

ERROR: Could not commit changes to layer

I first thought I made an error in the permissions, but after checking all seems to be correct there. Anyone has experience with WFS-t in GeoServer? I'm note quite sure where the error could be. Some things I came accross:

  • Some other errors related to OpenLayers+WFS editting pointed to 'Cross Origin Requests' and suggested to enable 'Cross-Origin Resource Sharing'.
  • I heard that the default settings for WFS have changed in newer versions of GeoServer. Does that relate to more things than just the default setting of the WFS service level?
  • Am I missing anything regarding the role settings? Does it suffice for WFS-t editing to give write access of that layer to a role?

Otherwise: does anyone know of a public WFS-t service I could use for testing if the error is not with QGIS?


Full layout of the GeoServer setup: I'm using GeoServer 2.10.0 on a Windows 2012 server. I followed these steps to set up users and permissions and these to enable WFS-t. The result is:

  • stores:
    • one store, connected to postgis on localhost
  • workspaces:
    • workspace_private
  • roles (under the default 'role service'):
    • role_private_view
    • role_private_edit
  • users (under the default 'user group service')
    • user_private_view, connected to: role_private_view
    • user_private_edit, connected to: role_private_edit. This is the user I use to login to the WFS.
  • Permissions:
    • Restrict viewing of private layers: read access in private workspace to role_private_view + role_private_edit
    • Allow editing of the private layers: write access in private workspace to role_private_edit
    • Allow read-write access to vector data through transactions Services by setting WFS service level to 'Transactional'

The roles thus look like this: Roles

The GeoServer log says (replaced url by XXX and layer by YYY):

2016-12-16 00:34:01,225 INFO [geoserver.wfs] - 
Request: getServiceInfo
2016-12-16 00:34:01,267 INFO [geoserver.wfs] - 
Request: getServiceInfo
2016-12-16 00:34:01,282 ERROR [geoserver.ows] - 
org.geoserver.wfs.WFSException: Could not find type: {http://XXX/geoserver/workspace_private}YYY
    at org.geoserver.wfs.DescribeFeatureType.run(DescribeFeatureType.java:163)
    at org.geoserver.wfs.DefaultWebFeatureService.describeFeatureType(DefaultWebFeatureService.java:105)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
...
    at org.eclipse.jetty.server.Server.handle(Server.java:499)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
    at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
    at java.lang.Thread.run(Unknown Source)
2016-12-16 00:34:01,374 ERROR [geoserver.ows] - 
java.lang.NullPointerException
    at org.geotools.xml.impl.SchemaIndexImpl.buildElementIndex(SchemaIndexImpl.java:382)
    at org.geotools.xml.impl.SchemaIndexImpl.getElementIndex(SchemaIndexImpl.java:320)
    at org.geotools.xml.impl.SchemaIndexImpl.getElementDeclaration(SchemaIndexImpl.java:130)
    at org.geotools.xml.impl.HandlerFactoryImpl.createElementHandler(HandlerFactoryImpl.java:39)
    at org.geotools.xml.impl.DocumentHandlerImpl.createChildHandler(DocumentHandlerImpl.java:76)
    at org.geotools.xml.impl.ParserHandler.startElement(ParserHandler.java:562)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
...
    at org.eclipse.jetty.server.Server.handle(Server.java:499)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
    at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
    at java.lang.Thread.run(Unknown Source)

closed as off-topic by Ian Turton Jul 4 '17 at 13:08

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This problem cannot or can no longer be reproduced. Changes to the system or to the asker's circumstances may have rendered the question obsolete, or the question does not include a procedure to enable potential answerers to reproduce the same symptoms. Such questions are off-topic as they are unlikely to help future readers, but editing them to include more details can lead to re-opening." – Ian Turton
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    There are known bugs/issues in recent QGIS (2.16 and newer) when it comes to WFS-T. GeoServer 2.10.1 will have some workarounds for the faulty requests that QGIS is building. I'm however not sure they are a match to your case though. You can have a look here: osgeo-org.atlassian.net/browse/GEOS-7888 and osgeo-org.atlassian.net/browse/GEOS-7895 – Andrea Aime Dec 18 '16 at 14:36
  • 1
    Ah, I've also found out that when editing the WFS connection, the "authentication" tab for "simple auth" is not effective, one has to go in the "configuration" tab and add a basic authentication configuration. Unsure what the authors mean by "simple authentication", http basic auth is as simple as it gets... – Andrea Aime Dec 18 '16 at 14:45
  • Thanks for the fast response @AndreaAime! Sadly, an alternate authentication via the "configuration" tab did not make it work and running the current snapshot build also didn't fix it :( – mclaeysb Dec 19 '16 at 10:40
  • 1
    I believe stackexchange has become unsuitable for this kind of question then, it's more of a debugging problem than a straigth question/answer type. I'd ask on the geoserver-users mailing list instead, ideally you could prepare a self contained example using the data dir geoserver is shipping with (it's small, easy to transfer to a developer and easier to discuss because everybody can get it and reproduce) – Andrea Aime Dec 19 '16 at 17:56