TCK Challenge Managed(Scheduled)ExecutorDefinitionTests.testCompletedFuture(MSE) Tests

[aubi]

Specification:

Jakarta Concurrency 3.0.0

Challenged test(s):

ee.jakarta.tck.concurrent.spec.ManagedExecutorService.resourcedef.ManagedExecutorDefinitionTests#testCompletedFuture

ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.resourcedef.ManagedScheduledExecutorDefinitionTests#testCompletedFutureMSE

TCK version:

3.0.0

Tested implementation:

Payara 6 (branch) with Concurrent-RI (branch)

Description

Test ManagedExecutorDefinitionTests/ManagedExecutorDefinitionServlet.testCompletedFuture uses "java:module/concurrent/ExecutorB" ManagedExecutorService, which is configured to use this context:

@ContextServiceDefinition(name = "java:module/concurrent/ContextB",
                          cleared = TRANSACTION,
                          unchanged = { APPLICATION, IntContext.NAME },
                          propagated = ALL_REMAINING)

E.g. the implementation must keep APPLICATION (JNDI search) unchanged during the thenAcceptAsync() call.

This test expects, that the thread's context doesn't recognize java:module JNDI lookup. As I understand, Open Liberty starts threads with "empty contexts", so JNDI calls fail and TCK test succeeds.

The same happens in ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.resourcedef.ManagedScheduledExecutorDefinitionService#testCompletedFutureMSE

A message from Nathan:

It looks like a mistake in the test case where it is accidentally testing the ‘unchanged’ setting as though it were ‘cleared’. The unchanged setting leaves the context type alone, so whatever the context was on the thread before it must remain. The mistake went unnoticed on Open Liberty because the state of the thread happens to already match the test assertion. This one should definitely be challenged for the mistaken assertion.

[scottmarlow]

As per TCK Process this challenge should be accepted via lazy consensus.

[aubi]

delete -> The fix for this challenge is here: #212
It removes changes of context between JNDI lookup and newThread, so both ways of understanding will be accepted.

Of course, we should agree on a final, more exact behavior, write it to doc and return the detailed tests.<-- delete

There is no fix - either we should use the cleared for APPLICATION or we should call the unchanged APPLICATION from well-defined thread.

[smillidge]

I accepted the challenge and will disable the test in the 3.0.1 TCK service release