[Geoserver-devel] Committing new Feature to Geoserver 1.6.3

Hi,

I’ve done some research for a uDig user. For Geoserver 1.6.3 uDig can’t add new features to a postgis via the WFS-T protocol. I’ve tested 1.5.4 and it work fine. The problem seems to be an xml parsing problem.
Seems the same problem occurs when editing shapefiles.

I notice that there aren’t default values for the category attribute that may have something to do with the problem.

Here’s the request and the stack trace for adding a feature to streams, let me know if you want the debug level higher. But this is really easy to reproduce. Just add a new feature with uDig and commit:



<sf:streams fid=“newsf:streams.9223372036854775807”>
sf:the_geom
<gml:MultiLineString srsName=“EPSG:26713”>
gml:lineStringMember
gml:LineString
<gml:coordinates decimal=“.” cs=“,”
ts=" ">
608364.9454970448,4923977.149388677
607848.5573049984,4923262.150353537
609119.6667008048,4922586.873487014
611026.3307945146,4923540.20553387
</gml:coordinates>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString>
</sf:the_geom>
sf:cat</sf:cat>
</sf:streams>

15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.opengis.net/wfs,Insert,Insert
15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.openplans.org/spearfish,streams,sf:streams
15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.openplans.org/spearfish,the_geom,sf:the_geom
15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.opengis.net/gml,MultiLineString,gml:MultiLineString
15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.opengis.net/gml,lineStringMember,gml:lineStringMember
15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.opengis.net/gml,LineString,gml:LineString
15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.opengis.net/gml,coordinates,gml:coordinates
15 Apr 07:59:55 TRACE [org.geotools.xml] - startElement(http://www.openplans.org/spearfish,cat,sf:cat
15 Apr 07:59:55 WARN [org.geoserver.ows] -
java.lang.RuntimeException: Parsing failed for cat: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at org.geotools.xml.impl.ParseExecutor.visit(ParseExecutor.java:142)
at org.geotools.xml.impl.BindingWalker$BindingExecutionChain.execute(BindingWalker.java:197)
at org.geotools.xml.impl.BindingWalker.walk(BindingWalker.java:163)
at org.geotools.xml.impl.ElementHandlerImpl.endElement(ElementHandlerImpl.java:222)
at org.geotools.xml.impl.ParserHandler.endElement(ParserHandler.java:499)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.geotools.xml.Parser.parse(Parser.java:185)
at org.geotools.xml.Parser.parse(Parser.java:164)
at org.geoserver.wfs.xml.v1_0_0.WfsXmlReader.read(WfsXmlReader.java:60)
at org.geoserver.ows.Dispatcher.parseRequestXML(Dispatcher.java:1072)
at org.geoserver.ows.Dispatcher.dispatch(Dispatcher.java:389)
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:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
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.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:303)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:735)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:636)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:558)
at org.geotools.xs.bindings.XSLongBinding.parse(XSLongBinding.java:90)
at org.geotools.xml.impl.ParseExecutor.visit(ParseExecutor.java:128)
… 64 more

Jesse Eichar ha scritto:

Hi,

I've done some research for a uDig user. For Geoserver 1.6.3 uDig can't add new features to a postgis via the WFS-T protocol. I've tested 1.5.4 and it work fine. The problem seems to be an xml parsing problem. Seems the same problem occurs when editing shapefiles.

Hi Jesse,
thanks for reporting, seems like a legitimate bug in xml parsing.
Can you create a jira issue attaching the request, the stack trace,
and a sample shapefile to reproduce the issue?

Cheers
Andrea

Will do.
On 15-Apr-08, at 9:49 AM, Andrea Aime wrote:

Jesse Eichar ha scritto:

Hi,
I've done some research for a uDig user. For Geoserver 1.6.3 uDig can't add new features to a postgis via the WFS-T protocol. I've tested 1.5.4 and it work fine. The problem seems to be an xml parsing problem. Seems the same problem occurs when editing shapefiles.

Hi Jesse,
thanks for reporting, seems like a legitimate bug in xml parsing.
Can you create a jira issue attaching the request, the stack trace,
and a sample shapefile to reproduce the issue?

Cheers
Andrea

The wfs spec says that when an attribute is null it should be committed as a property, instead of included an empty. I am not sure the latter is valid.

However, I would say we should be lax in this case, I have run into the same issue with openlayers wfs client as well.

Jesse Eichar wrote:

Will do.
On 15-Apr-08, at 9:49 AM, Andrea Aime wrote:

Jesse Eichar ha scritto:

Hi,
I've done some research for a uDig user. For Geoserver 1.6.3 uDig can't add new features to a postgis via the WFS-T protocol. I've tested 1.5.4 and it work fine. The problem seems to be an xml parsing problem. Seems the same problem occurs when editing shapefiles.

Hi Jesse,
thanks for reporting, seems like a legitimate bug in xml parsing.
Can you create a jira issue attaching the request, the stack trace,
and a sample shapefile to reproduce the issue?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,480461e2180932085621377!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Justin Deoliveira ha scritto:

The wfs spec says that when an attribute is null it should be committed as a property, instead of included an empty. I am not sure the latter is valid.

Right right... yet, what if for any strange reason the user really
wanted to provide an empty string as the value?
Would not be the following valid?

<sf:cat></sf:cat>

Or is "cat" a numeric value? In that case the above would not make
sense I guess.

Cheers
Andrea