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

ensures reactor is backward compatible with latest context propagation changes #3493

Merged
merged 6 commits into from
Jun 12, 2023

Conversation

OlegDokuka
Copy link
Contributor

@OlegDokuka OlegDokuka commented Jun 8, 2023

followup to #3489

this PR incorporates old changes with the new ones so it makes the reactor backward compatible with context-propagation libs <= 1.0.2

…n changes

Signed-off-by: OlegDokuka <odokuka@vmware.com>
@OlegDokuka OlegDokuka requested a review from a team as a code owner June 8, 2023 16:27
@OlegDokuka OlegDokuka added the type/enhancement A general enhancement label Jun 8, 2023
@OlegDokuka OlegDokuka added this to the 3.5.7 milestone Jun 8, 2023
Signed-off-by: OlegDokuka <odokuka@vmware.com>
Copy link
Member

@chemicL chemicL left a comment

Choose a reason for hiding this comment

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

Thanks for taking care of the backwards compatibility. I think we need to handle non-automatic mode differently and use the ContextSnapshot.setAllThreadLocals call directly instead of ContextPropagationl.setThreadLocals.

}

@SuppressWarnings("unchecked")
static <C> ContextSnapshot.Scope setThreadLocals(Object context) {
Copy link
Member

Choose a reason for hiding this comment

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

This method can't be used when automatic context propagation is not enabled - every handle/tap setThreadLocal call did behave differently with regard to missing values - with this change it would clear ThreadLocals for values missing in the context, which is not the case in 3.5.6.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right! Good catchup! My bad missed that pice! Thanks

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

OlegDokuka added 4 commits June 9, 2023 09:18
Signed-off-by: OlegDokuka <odokuka@vmware.com>
Signed-off-by: OlegDokuka <odokuka@vmware.com>
Signed-off-by: OlegDokuka <odokuka@vmware.com>
Signed-off-by: OlegDokuka <odokuka@vmware.com>
@OlegDokuka OlegDokuka requested a review from chemicL June 9, 2023 10:44
Copy link
Contributor

@rstoyanchev rstoyanchev left a comment

Choose a reason for hiding this comment

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

Overall looks good. However, while use of ContextSnapshotFactory is protected with classpath checks, having it as a static variable leaves it open to potential classpath issues, e.g. some debugger introspecting variables and running into classpath issues it does not expect.

To really isolate the dependency, you could create an internal (private) interface to capture, set thread locals, etc. Then have one implementation for 1.0.3 and another for the existing code. Similar to the SignalListener implementations but behind a private interface.

On the other hand, I expect all these changes to be relatively short-lived. They are only there to cushion the transition to the next maintenance release, and not long after can be phased out. In light of that, the current changes may be good enough for a brief transition period.

@OlegDokuka OlegDokuka merged commit 898aea4 into main Jun 12, 2023
@chemicL chemicL deleted the main-cp-102-compatibility branch April 11, 2024 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants