[Geoserver-devel] Cannot insert/update WFS features with line breaks

GeoServer GeoServer Developer
1

Hi,

I cannot update WFS features with properties containing line breaks. It is already reported in JIRA [1] and in the list previously [2].

I made some research and added my conclusions to the issue in JIRA. Basically it seems like the XML value element is treated as a mixed ComplexType and their white spaces are collapsed. Using CDATA produces the same result.

I’m a bit lost here about the reason for this. Is this a bug with the parser and/or xsd processing? Does the xsd force the collapsing of these values by definition? Why is CDATA ignored?

Thanks in advance.

[1] https://osgeo-org.atlassian.net/browse/GEOS-8227
[2] http://osgeo-org.1560.x6.nabble.com/Line-breaks-transaction-geoserver-td5056634.html

···

Víctor González

http://geomati.co

2

How are you sending the XML? I had issues with curl removing the linebreaks from files sent as ASCII, if you send it as binary data then the line breaks survive. As far as I recall the parser should handle linebreaks correctly if they are present,

Ian

···

On 5 September 2017 at 11:15, Víctor González <victor.gonzalez@anonymised.com> wrote:

Hi,

I cannot update WFS features with properties containing line breaks. It is already reported in JIRA [1] and in the list previously [2].

I made some research and added my conclusions to the issue in JIRA. Basically it seems like the XML value element is treated as a mixed ComplexType and their white spaces are collapsed. Using CDATA produces the same result.

I’m a bit lost here about the reason for this. Is this a bug with the parser and/or xsd processing? Does the xsd force the collapsing of these values by definition? Why is CDATA ignored?

Thanks in advance.

[1] https://osgeo-org.atlassian.net/browse/GEOS-8227
[2] http://osgeo-org.1560.x6.nabble.com/Line-breaks-transaction-geoserver-td5056634.html

–

Víctor González

http://geomati.co

Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Ian Turton

3

Thanks! With --data-binary insert works. Now I got to the same problem reported in JIRA. Works with insert, fails with update.

I debugged and checked that the request arrived correctly with line breaks up to this point: https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java#L1581

Also debugging I found that the wfs:Value element has its whitspaces collapsed in the preParse method because it’s a mixed ComplexType:
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-core/src/main/java/org/geotools/xml/impl/ParseExecutor.java#L332

···

2017-09-05 14:15 GMT+02:00 Ian Turton <ijturton@anonymised.com>:

How are you sending the XML? I had issues with curl removing the linebreaks from files sent as ASCII, if you send it as binary data then the line breaks survive. As far as I recall the parser should handle linebreaks correctly if they are present,

Ian

–

On 5 September 2017 at 11:15, Víctor González <victor.gonzalez@anonymised.com> wrote:

Hi,

I cannot update WFS features with properties containing line breaks. It is already reported in JIRA [1] and in the list previously [2].

I made some research and added my conclusions to the issue in JIRA. Basically it seems like the XML value element is treated as a mixed ComplexType and their white spaces are collapsed. Using CDATA produces the same result.

I’m a bit lost here about the reason for this. Is this a bug with the parser and/or xsd processing? Does the xsd force the collapsing of these values by definition? Why is CDATA ignored?

Thanks in advance.

[1] https://osgeo-org.atlassian.net/browse/GEOS-8227
[2] http://osgeo-org.1560.x6.nabble.com/Line-breaks-transaction-geoserver-td5056634.html

–

Víctor González

http://geomati.co

Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Ian Turton

Víctor González

http://geomati.co

4

I had a partial PR for this issue at https://github.com/geotools/geotools/pull/1595 but I closed it out when I found it was curl eating my newlines.

Can you generate a test case and I can look at finishing that off

Ian

···

On 6 September 2017 at 09:53, Víctor González <victor.gonzalez@anonymised.com> wrote:

Thanks! With --data-binary insert works. Now I got to the same problem reported in JIRA. Works with insert, fails with update.

I debugged and checked that the request arrived correctly with line breaks up to this point: https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java#L1581

Also debugging I found that the wfs:Value element has its whitspaces collapsed in the preParse method because it’s a mixed ComplexType:
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-core/src/main/java/org/geotools/xml/impl/ParseExecutor.java#L332

–

2017-09-05 14:15 GMT+02:00 Ian Turton <ijturton@anonymised.com>:

How are you sending the XML? I had issues with curl removing the linebreaks from files sent as ASCII, if you send it as binary data then the line breaks survive. As far as I recall the parser should handle linebreaks correctly if they are present,

Ian

–

Víctor González

http://geomati.co

On 5 September 2017 at 11:15, Víctor González <victor.gonzalez@anonymised.com> wrote:

Hi,

I cannot update WFS features with properties containing line breaks. It is already reported in JIRA [1] and in the list previously [2].

I made some research and added my conclusions to the issue in JIRA. Basically it seems like the XML value element is treated as a mixed ComplexType and their white spaces are collapsed. Using CDATA produces the same result.

I’m a bit lost here about the reason for this. Is this a bug with the parser and/or xsd processing? Does the xsd force the collapsing of these values by definition? Why is CDATA ignored?

Thanks in advance.

[1] https://osgeo-org.atlassian.net/browse/GEOS-8227
[2] http://osgeo-org.1560.x6.nabble.com/Line-breaks-transaction-geoserver-td5056634.html

–

Víctor González

http://geomati.co

Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Ian Turton

Ian Turton