GeoServer

WFSV does not include all of the functions of WFS; "insert" request not supported

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: Community
  • Component/s: Versioning
  • Labels:
    None
  • Number of attachments :
    0

Description

My initial impression of WFSV was that it was a superset of WFS; that is, it contained all the functions of WFS, plus versioning support. However, it seems as though an INSERT request – and presumably other requests – are not supported by WFSV.

Here's an example request:

<wfsv:Transaction xmlns:wfsv="http://www.opengis.net/wfsv" version="1.0.0" service="WFSV" outputFormat="GML2" xmlns:topp="http://www.openplans.org/topp" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfsv http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-versioning.xsd"><wfsv:Insert><topp:comments xmlns:topp="http://www.openplans.org/topp"><topp:title> </topp:title><topp:comment>asdfas
</topp:comment><topp:notes_gid>36</topp:notes_gid></topp:comments></wfsv:Insert></wfsv:Transaction>

Notice the "wfsv" in places where "wfs" would normally show. I would expect this request to function as it would had it been a normal WFS request; however, here's the result:

<?xml version="1.0" ?>
<ServiceExceptionReport
version="1.2.0"
xmlns="http://www.opengis.net/ogc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd">

<ServiceException>
Could not find request reader for: net.opengis.wfs.TransactionType
Details:
org.geoserver.platform.ServiceException: Could not find request reader for: net.opengis.wfs.TransactionType

at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:382)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:185)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)

</ServiceException></ServiceExceptionReport>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tim Coulter added a comment -

Just for symmetry, here's a valid insert request:

<wfs:Transaction xmlns:wfs="http://www.opengis.net/wfs" version="1.0.0" service="WFS" outputFormat="GML2"
xmlns:topp="http://www.openplans.org/topp" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><wfs:Insert><topp:comments xmlns:topp="http://www.openplans.org/topp"><topp:title> </topp:title><topp:comment>iiiiiiiii</topp:comment><topp:notes_gid>36</topp:notes_gid></topp:comments></wfs:Insert></wfs:Transaction>

Show
Tim Coulter added a comment - Just for symmetry, here's a valid insert request: <wfs:Transaction xmlns:wfs="http://www.opengis.net/wfs" version="1.0.0" service="WFS" outputFormat="GML2" xmlns:topp="http://www.openplans.org/topp" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><wfs:Insert><topp:comments xmlns:topp="http://www.openplans.org/topp"><topp:title> </topp:title><topp:comment>iiiiiiiii</topp:comment><topp:notes_gid>36</topp:notes_gid></topp:comments></wfs:Insert></wfs:Transaction>
Hide
Permalink
Andrea Aime added a comment - - edited

Tim,
for what I can see this is a misinterpretation of what xml schema is on your part.
The second request is the valid one. WFSV does not define a transaction element because it's already defined in the wfs namespace, yet it is a clean extension from the xml schema point of view, in that its extra elements share parts of the wfs definitions.

We are thinking of removing the wfsv namespace altogheter since it's causing more confusion than benefits, but for the moment when composing a service call look in the xml schemas and see in which namespace each element is declared, or add strict=true as a get parameter to your request to make geoserver perform a full validation of the document you're posting and GeoServer will tell you that the first request you pasted is invalid according to the wfs and wfsv schema.
For more information about per request validation see:
http://docs.codehaus.org/display/GEOSDOC/WFS+vendor+parameters#WFSvendorparameters-validation

Show
Andrea Aime added a comment - - edited Tim, for what I can see this is a misinterpretation of what xml schema is on your part. The second request is the valid one. WFSV does not define a transaction element because it's already defined in the wfs namespace, yet it is a clean extension from the xml schema point of view, in that its extra elements share parts of the wfs definitions. We are thinking of removing the wfsv namespace altogheter since it's causing more confusion than benefits, but for the moment when composing a service call look in the xml schemas and see in which namespace each element is declared, or add strict=true as a get parameter to your request to make geoserver perform a full validation of the document you're posting and GeoServer will tell you that the first request you pasted is invalid according to the wfs and wfsv schema. For more information about per request validation see: http://docs.codehaus.org/display/GEOSDOC/WFS+vendor+parameters#WFSvendorparameters-validation
Hide
Permalink
Andrea Aime added a comment - - edited

One more example. If you make a transaction service call you'll probably be using the gml and ogc namespaces. If you look into capabilities you may use the ows namespace one. All this things do work like library imports, you have elements definitions that you are using.
In the case of wfsv, the xml schema defines only the extra elements it needs, and reuses everything else from wfs and other namespaces. Since we do not need to alter Transaction and the associated elements the prefix remains wfs, we haven't redefined it.
Does this make sense?

Show
Andrea Aime added a comment - - edited One more example. If you make a transaction service call you'll probably be using the gml and ogc namespaces. If you look into capabilities you may use the ows namespace one. All this things do work like library imports, you have elements definitions that you are using. In the case of wfsv, the xml schema defines only the extra elements it needs, and reuses everything else from wfs and other namespaces. Since we do not need to alter Transaction and the associated elements the prefix remains wfs, we haven't redefined it. Does this make sense?

People

  • Assignee:
    Andrea Aime
    Reporter:
    Tim Coulter
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: