Ondro Mihályi

I thought about this for a while and basically agree with all views presented: * I agree with @njr-11 that the spec suggests that the context is captured when the...

> While I agree that it seems more intuitive to capture context at thread creation, it also seems like that could lead to confusion, if you're running the same task...

> which is where the JNDI lookup is performed in order to inject it, so it would capture the context that is on the thread during the initialization of that...

What about using the first approach when there’s only one definition and the second when there are more definitions? If the first approach is used with multiple definitions, deployment would...

However, @Resource would still be needed to refer to executors defined outside of the app. But it’s not worth dropping support for that and replace it with another annotation. @Resource...

> For this issue, we should also decide if this constitutes a breaking change such that the next version of Concurrency should be 4.0 rather than 3.1. It seems to...

True. It would rather have to be something like: ``` @ManagedExecutorDefinition(qualifiers = MyExecutor.class, ...) @ApplicationScoped public class ExampleBean { ```

Yes, you’re right, I confused executors and factories. I still think that it would be more intuitive and in line with executors to capture the context when newThread is called....

Thank you, @njr-11 , for explanation and citations from the spec. You're right, the spec suggests that all threads created by a factory have the same context by default. However,...

Only this part of the specification suggests that the context should be the context of the application component that retrieved the factory: > All Threads are contextual (see section 2.3)....