-
Notifications
You must be signed in to change notification settings - Fork 39
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
Fix ContextB application in cleared #255
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a couple of comments. Please disregard my earlier comment about needing to find a different follow-up reviewer. It looks like I'll be working this week with the other plans now cancelled due to COVID still present in the household, so I should be able to review updates after all.
@@ -259,6 +259,10 @@ public void testContextualConsumer() throws Throwable { | |||
* A ContextService contextualizes a Function, which can be supplied as a dependent stage action | |||
* to an unmanaged CompletableFuture. The dependent stage action runs with the thread context of | |||
* the thread that contextualizes the Function, per the configuration of the ContextServiceDefinition. | |||
* | |||
* Assertions on results[0] and results[1] are both invalid because treating those two UNCHANGED context types as | |||
* though they were CLEARED. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment seems out of place given that this pull is attempting to correct the assertion on results[0] to make it valid.
cleared = TRANSACTION, | ||
unchanged = { APPLICATION, IntContext.NAME }, | ||
cleared = {TRANSACTION, APPLICATION}, | ||
unchanged = { IntContext.NAME }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making this change would only correct the assertion on APPLICATION context and not the subsequent assertion on IntContext. Also, is it safe with respect to all of the other TCK tests that use "java:module/concurrent/ContextB" to alter this configuration? It seems like the safest change would be to either adjust the assertions to match the specified annotation values, or otherwise create an additional ContextServiceDefinition with values that the assertions expect.
In the tests, ContextB's APPLICATION is tested to be cleared. This PR changes it from unchanged to cleared and enables all related challenged tests.