Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GEOT-7365] Problems with requesting Features from a WFS Version 2.0.0 and using a HTTP proxy #4306

Merged
merged 1 commit into from
Jun 9, 2023

Conversation

roarbra
Copy link
Contributor

@roarbra roarbra commented May 31, 2023

GEOT-7365 Powered by Pull Request Badge

Injecting HTTPClient into XSD handling to take advantage of any configuration set in WFSDataStore or proxy setting.

In addition made some changes to the exception's thrown, and the exception that is passed if fetching the schema fails.

Checklist

For core and extension modules:

  • New unit tests have been added covering the changes.
  • Documentation has been updated (if change is visible to end users).
  • There is an issue in GeoTools Jira (except for changes not visible to end users).
  • Commit message(s) must be in the form [GEOT-XYZW] Title of the Jira ticket.
  • Bug fixes and small new features are presented as a single commit.
  • The commit targets a single objective (if multiple focuses cannot be avoided, each one is in its own commit, and has a separate ticket describing it).

Copy link
Member

@mprins mprins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@aaime aaime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just a question below.

@@ -172,7 +172,7 @@ public SimpleFeatureIterator features() {
try {
return new WrappingFeatureIterator(featureSource.getReader(query));
} catch (IOException e) {
throw new RuntimeException(e);
throw new RuntimeException(e.getMessage(), e);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this improve error reporting somehow?
Quoting from the previously used constructor javadoc:

Constructs a new runtime exception with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause). This constructor is useful for runtime exceptions that are little more than wrappers for other throwables.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have noticed that by using the first approach, and nesting in several try-catch, we will end up with the exception message: "[java.lang.RuntimeException] [java.io.IOException] [java.sql.SQLException] Couldn't open connection."
I think those class names in front are misleading. Especially when they are sent in a ServiceException.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants