Closed FroMage closed 6 years ago
Rewriting my prior comment because I just realized this issue is likely referring to how the ManagedExecutor/ThreadContext instances are obtained and configured via CDI @Inject. Are you thinking that we need a builder pattern as an alternative so that CDI can be optional? Or would it be sufficient to be able to obtain as EE Concurrency ManagedExecutorService/ContextService and cast those to ManagedExecutor/ThreadContext? The latter is written in a long term goal, but we could certainly make it a requirement that if an implementation provides both, the instances must be interchangeable.
Yes I meant that I only see a way to access the ThreadContext
via @Inject
. I don't want to rely on EE Concurrency either because RESTEasy and Weld can both run outside of an EE container, and context propagation should work in SE too.
Thanks for clarifying. You have a good point there and it is definitely something we want to allow for. I previously mentioned the builder pattern as a more comprehensive solution, but there are also simpler options such as a static method on ThreadContext (and ManagedExecutor) to obtain an instance that propagates all provided context types. And I'm sure there are plenty of other possible approaches besides these. Do you have specific ideas to consider here?
In order for mp-concurrency to replace Reactive Contexts which is currently used by RESTEasy to provide context propagation, I suspect we will need to be able to obtain a
TreadContext
implementation without CDI, because RESTEasy-core does not depend on CDI.Keeping the dependencies of mp-concurrency would allow it to be more broadly used. A CDI implementation could be provided as an optional dependency.