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]<mailto:[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]<mailto:[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
