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

Make checks for existence of ThreadLocal more robust #1136

Merged
merged 1 commit into from Jun 2, 2017

Conversation

arteam
Copy link
Member

@arteam arteam commented Jun 2, 2017

We should try to load an actual value of a ThreadLocal, because in some environments (like WebLogic) a NoClassDefException won't be thrown during loading of JdkProvider.

We should also catch all possible errors, not only NoClassDefException to avoid a situation when the provider becomes a null reference.

Originally reported in #1129

We should try to load an actual value of a ThreadLocal, because
in some environments (like WebLogic) a `NoClassDefException` won't
be thrown during loading of `JdkProvider`.

We should also catch all possible errors, not only `NoClassDefException`
to avoid a situation when the provider becomes a null reference.
@arteam arteam added this to the 3.1.5 milestone Jun 2, 2017
@arteam arteam merged commit 469600d into 3.1-maintenance Jun 2, 2017
@arteam arteam deleted the more_robust_jdk_check branch June 2, 2017 08:37
arteam added a commit that referenced this pull request Jun 2, 2017
We should try to load an actual value of a ThreadLocal, because
in some environments (like WebLogic) a `NoClassDefException` won't
be thrown during loading of `JdkProvider`.

We should also catch all possible errors, not only `NoClassDefException`
to avoid a situation when the provider becomes a null reference.

(cherry picked from commit 469600d)
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.

None yet

1 participant