Stop using illegal reflective access for setting cause during exception #251
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change removes illegal reflective access to the cause field in the
CheckedExceptionWrapper
replacing it with shallow unwrapping of the exception plus full unwrapping during serialization.The reason we need to keep shallow unwrapping instead of getting rid of it entirely is because there are a few places in the pre-serialization code that either log or conduct actions based on the client exception. Look at POJOWorkflowImplementationFactory and POJOActivityTaskHandler as examples.
One tradeoff that we have to make here is whether or not we want to eliminate a possibility of client seeing CheckedExceptionWrapper as current approach doesn't guarantee that and if there are multiple layers of wrappers inner layers might be visible in the log, logged by POJOActivityTaskHandler. Preferred way to solve it could be by transforming that exception to Failure before logging, alternatively we could reimplement unwrap by serializing to failure and back, which would eliminate all exception wrappers in the process.