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

[#41] Fail Gracefully when Debug Provider Invalid #42

Open
wants to merge 1 commit into
base: sustaining/13.5.x
Choose a base branch
from

Conversation

Kortanul
Copy link
Member

@Kortanul Kortanul commented Mar 2, 2019

  • Ensure that debug provider fallback is in place BEFORE trying to log any exceptions about failing to initialize the debug provider.
  • Upgrade openam-shared to JDK 8+ (see below).
  • Clean-up debug provider initialization.
    • Switch to multi-catch instead of repetitive catch blocks (JDK 7+).
    • Pull-in forgerock-guava-base to allow us to use Strings.isNullOrEmpty().
    • Switch to Optional to support chaining trim() on provider names without an explicit null check (JDK 8+).

Closes #41.

@Kortanul Kortanul added this to the wren:am 13.5 stable release milestone Mar 2, 2019
@Kortanul Kortanul force-pushed the feature/13.5.x/issue-41--debug-provider-fallback branch from fd3e0fc to 2078afa Compare March 2, 2019 04:48
@Kortanul Kortanul changed the title [#41] Fail Gracefully whenDebug Provider Invalid [#41] Fail Gracefully when Debug Provider Invalid Mar 2, 2019
- Ensure that debug provider fallback is in place BEFORE trying to log any exceptions about failing to initialize the debug provider.
- Upgrade `openam-shared` to JDK 8+ (see below).
- Clean-up debug provider initialization.
  - Switch to multi-catch instead of repetitive `catch` blocks (JDK 7+).
  - Pull-in `forgerock-guava-base` to allow us to use `Strings.isNullOrEmpty()`.
  - Switch to `Optional` to support chaining `trim()` on provider names without an explicit `null` check (JDK 8+).

Closes WrenSecurity#41.
@Kortanul Kortanul force-pushed the feature/13.5.x/issue-41--debug-provider-fallback branch from 2078afa to 842160c Compare March 2, 2019 04:50
try {
provider = (IDebugProvider) Class.forName(providerName).newInstance();
} catch (ClassNotFoundException cnex) {
provider = (IDebugProvider)Class.forName(providerName).newInstance();
Copy link
Member

Choose a reason for hiding this comment

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

I realize that this code was already here but isn't newInstance considered evil? The docs say:

Note that this method propagates any exception thrown by the nullary constructor, including a checked exception. Use of this method effectively bypasses the compile-time exception checking that would otherwise be performed by the compiler. The Constructor.newInstance method avoids this problem by wrapping any exception thrown by the constructor in a (checked) InvocationTargetException.

provider = (IDebugProvider) Class.forName(providerName).newInstance();
} catch (ClassNotFoundException cnex) {
provider = (IDebugProvider)Class.forName(providerName).newInstance();
} catch (ClassNotFoundException
Copy link
Member

Choose a reason for hiding this comment

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

Is there a point in catching specific exceptions? Doesn't any exception mean the provider failed to load? How would we deal with newer Java version throwing other exceptions?

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

Successfully merging this pull request may close these issues.

2 participants