Hi all,
I am currently preparing an implementation as proposal for a proper
WFSException on Transaction errors. But I have a problem with the parsing of
the XML ExceptionReport:
- Using WFS 2.0 and 1.1 the parsing of the ExceptionReport works out of the box
- Using WFS 1.0 the parsing doesnt work and results in a Map instead.
What I found out so far:
* This is apparently because the parser misses the respective bindings.
* The parser is configured with a org.geotools.wfs.v1_0.WFSConfiguration.
* wfs.v1_0.WFSConfiguration has one dependency only:
org.geotools.filter.v1_0.OGCConfiguration.
* v1_0.OGCConfiguration doesnt contain the definitions for the ExceptionReport.
* But org.geotools.ows.OWSConfiguration contains the definitions for the
ExceptionReport. I tried to add ows.OWSConfiguration as dependency to
wfs.v1_0.WFSConfiguration and the parsing works fine.
* But ows.OWSConfiguration has a dependency to
org.geotools.filter.v1_1.OGCConfiguration. So I think I should not add
ows.OWSConfiguration as a dependency to v1_0.WFSConfiguration, because it would
mix up WFS 1.0 and 1.1.
I suppose this structure is a result of the offical XSDs: The WFS 1.0 XSD does
not include the OGC-exception.xsd, too. And the GT configuration classes
reflect this. In later WFS versions the WFS.xsd also includes the exceptions.
So maybe its a problem with the specification XSDs already.
I need some advice on how to carry on here:
How can I configure the parser for WFS 1.0 and enable it to parse
ExceptionReports?
Best regards,
Andreas
Von: Watermeyer, Andreas
Gesendet: Freitag, 1. September 2017 11:04:54
An: Jody Garnett
Cc: [email protected]
Betreff: AW: [Geotools-devel] WFS-NG: Server exception gets lost for
Transaction requests
Hi Jody,
> For me the big thing that was lost going from wfs --> wfs-ng was the WFS
>specific TransactionState, the replacement replies on the the > same
>TransactionStateDiff as ShapefileDataStore resulting in extra requests to the
>server to determine feature ids to use as key in the > diff map.
I was not aware of the difference. Looking at the code I found the mechanism
quite complex. I am not so familiar with that part of geotools, but as far as I
see, that has no influence on the exception handling or do I miss anything
important?
Best regards,
Andreas
Von: Jody Garnett <[email protected]>
Gesendet: Freitag, 1. September 2017 05:28:46
An: Watermeyer, Andreas
Cc: [email protected]
Betreff: Re: [Geotools-devel] WFS-NG: Server exception gets lost for
Transaction requests
I like your suggestion on error reporting.
For me the big thing that was lost going from wfs --> wfs-ng was the WFS
specific TransactionState, the replacement replies on the the same
TransactionStateDiff as ShapefileDataStore resulting in extra requests to the
server to determine feature ids to use as key in the diff map.
--
Jody Garnett
On 31 August 2017 at 01:22, Watermeyer, Andreas
<[email protected]> wrote:
Hi all,
we are using the wfs-ng module as a WFS client. Unfortunately, for Transaction
requests WFS exception responses are dropped by the client and instead an
empty IOException is thrown (TransactionResponseImpl.java:105, see
https://github.com/geotools/geotools/blob/cfe895c1fe84c65904d1aa383496ed2aff7afa42/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/internal/v1_x/TransactionResponseImpl.java#L105).
A better solutions is already implemented for the GetFeature case
(AbstractGetFeatureResponseParserFactory#createResponse, see
https://github.com/geotools/geotools/blob/cfe895c1fe84c65904d1aa383496ed2aff7afa42/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/internal/parsers/AbstractGetFeatureResponseParserFactory.java#L108).
I'd like to propose a pull request, where this solution is also applied to the
Transaction case.
One thing is however not so nice from my point of view:
AbstractGetFeatureResponseParserFactory.parseException(...) creates an
ExceptionReportType having a list of code+message pairs. This information is
converted into a plain WFSException retaining a concatenated string field
only.
Suggestion: Introduce a subclass of WFSException which keeps this information
separately to be easier accessible for consumers.
Before I start to work on it:
- Are there better/alternative suggestions? Any comments are welcome.
Best regards,
Andreas
PS: Also posted on geoserver users, but this is probably the better audience.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
