TCK Challenge ManagedThreadFactory tests, context save

[aubi]

Specification:

Jakarta Concurrency 3.0.0

Challenged test(s):

ee.jakarta.tck.concurrent.spec.ManagedThreadFactory.resourcedef.ManagedThreadFactoryDefinitionTests#testManagedThreadFactoryDefinitionAllAttributes

ee.jakarta.tck.concurrent.spec.ManagedThreadFactory.resourcedef.ManagedThreadFactoryDefinitionTests#testManagedThreadFactoryDefinitionAllAttributesEJB

ee.jakarta.tck.concurrent.spec.ManagedThreadFactory.resourcedef.ManagedThreadFactoryDefinitionTests#testParallelStreamBackedByManagedThreadFactory

ee.jakarta.tck.concurrent.spec.ManagedThreadFactory.resourcedef.ManagedThreadFactoryDefinitionTests#testParallelStreamBackedByManagedThreadFactoryEJB

ee.jakarta.tck.concurrent.spec.Platform.dd.DeploymentDescriptorTests#testDeploymentDescriptorDefinesManagedThreadFactory

TCK version:

3.0.0

Tested implementation:

Payara 6 (PR) with Concurrent-RI 3.0.0-RC1

Description

All the tests expect, that the context save happens at the moment of JNDI lookup (witch causes a creation of such ManagedThreadFactory in some implementations). The referential implementation always did the save in newThread(), as well as WildFly for example (https://www.eclipse.org/lists/cu-dev/msg00283.html).

I suggest to remove this requirement and modify the test to store the values before lookup, remove setting between lookup and newThread().
The exact behavior should be agreed and clarified, preferably in 3.1.

PR for the first 4 methods is here: #212

[smillidge]

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