SPI for propagation of third-party context types

[njr-11]

This pull copies over the SPI from MicroProfile Context Propagation that allows for third-party providers of thread context. This will be necessary for propagation of CDI context, for example, to be handled by a third-party implementation, such as Weld, but driven by the implementor of the Jakarta Concurrency specification.

One of the main decisions to make in adding this is whether the SPI should allow for serializable thread context to enable the 4 ContextService.createContextualProxy methods that let you create contextual proxies that can be serialized and deserialized across JVMs. MicroProfile avoided the need for serializable thread context by excluding these methods. We could do that, too, by declaring that the combination of third-party thread context with the createContextualProxy methods is only valid if the interface types are not serializable. That could simplify things for providers of third-party context. It could also be limiting in scenarios such as persistent (EJB) timers and potentially batch that might use the ContextService to store contextual tasks and expect them to be able to run on another JVM. I'll start a discussion on the mailing list about this.

An update to the above - I joined a call with the CDI spec group about this SPI, and the feedback from them is a strong preference to leave out the serializable aspect. Serialization gets too confusing and complex as to the very limited number of scenarios in which it could actually work. I have updated this pull with a second commit that takes away the serialization/deserialization of context. If anyone would like to see what it looked like prior to that point, that can be seen with just the first commit.

Signed-off-by: Nathan Rauh nathan.rauh@us.ibm.com

[scottmarlow]

Hi @njr-11 during the platform call today, you mentioned that the TCK tests for this would include a (mock) implementation and tests that use the mock implementation. Does that sound correct?

Will there be a volunteer to add the tests to https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/concurrency?

Thanks,
Scott

[njr-11]

Hi @njr-11 during the platform call today, you mentioned that the TCK tests for this would include a (mock) implementation and tests that use the mock implementation. Does that sound correct?

Will there be a volunteer to add the tests to https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/concurrency?

Thanks, Scott

@scottmarlow Yes. TCK tests for this will include a mock implementation of the ThreadContextProvider SPI, along with the TCK tests themselves driving the Jakarta Concurrency API to depend upon the mock ThreadContextProvider having transferred the mock context type to the async task or action, just as was done in the MicroProfile TCK for the equivalent SPI that we prototyped there. The location of the Concurrency TCK will be different that what you stated because the TCK is currently being ported over to the Concurrency project. If the TCK were already fully ported, then it would have been possible to include the TCK tests under the same pull as the spec updates.

[njr-11]

rebased and resolved the merge conflict, which was that this pull and the latest both added a new section to the same spot at the end of the main documentation file.