GeoServer
  1. GeoServer
  2. GEOS-1635

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

        Hide
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: