While thread factory and context service are quite trivial, the executors are a bit more complex, due to the spec decision to introduce the concepts of ManagedTask (+ related ManagedTaskListener), and Trigger scheduling, which go way beyond what in java.util.concurrent and IMHO just complicate the impl without providing key functionality.

Anyway what I did was a TaskDecorator family of ThreadPoolExecutors extensions, which simply are aware of tasks implementing specific interfaces, and delegate to these tasks the decoration of RunnableFutures. Then there are the managed executor services which wrap the original tasks, which contain all the logic to support the fancy features of the API, and delegate to the TaskDecorator executors. The module contains an extensive unit test suite, which (I think) validates every possible use case of the API.

The ee-concurrent does not includes any logic wrt setting the invocation context, that is provided in the ee extension through interceptors. I added another list of interceptors to the EE components, and when creating contextual objects these are used + a terminal invoking interceptor that uses reflection to the call, for instance for Runnable#run(). There is also a new ConcurrentContextInterceptor that goes into almost every of the other lists of interceptors, which is responsible for capturing the data needed to recreate context, and also to locate the actual JSR 236 managed objects, since the ones coming from jndi are just front ends not bound to a specific component (for instance one EJB may be injected with the DefaultManagedExecutorService, but if the context switches to another component than invoking the executor must then consider the actual component in context, not the one which did the lookup).

Additionally, there is a DUP that for each EE component adds its own JSR 236 managed objects, is responsible for doing the jndi bindings and interceptor setup, but note that the TaskDecorator executors, who actually have the execution resources such as threads, are shared by all, thus added along the subsystem. Also please note that right now there is no subsystem management wrt JSR 236 (that's the WFLY-238 last piece to be worked out next), there are only the default managed objects mandated by the spec, and without configuration, but still a draft of what I think we should have can be seen at https://github.com/wildfly/wildfly/pull/4705/files#diff-76

3) Integration tests - I added one for ManagedExecutorService and another for ManagedScheduledExecutorService, which both do a similar test, an EJB that submits/schedules a task, and upon task execution it's confirmed that security, class loading, naming and transaction contexts are correctly set and working, which are the ones required by the spec. I guess more should be added, but these already cover most of the functionality , good enough for the initial PR.

Tomaz recently brought this and the package/module names subjects to the mail list, but I don't think there was any real agreement on any. I think it's the best time for making "ee" just a maven parent, and move its sources to ee/extension, and then drop concurrent there too, instead of adding this new top level ee-concurrent maven module. Obviously we could instead just merge everything into "ee", but then we will never accomplish the EE breakup, and it's probably going to get messy in the future.

The interceptor that restores the security context depends on picketbox, and it shouldn't be on wildly-security, since an EE->Security dependency brings a circular dependency, so there is an EE->Picketbox dependency now, is this an issue or undesirable? Or perhaps there is an alternative to restore the security context that I'm not aware? The interceptor can be seen at https://github.com/wildfly/wildfly/pull/4705/files#diff-62

The current interceptors used can be seen at https://github.com/wildfly/wildfly/pull/4705/files#diff-55 , these are the ones the integrations tests required for everything there to work. Are there other interceptors that should be added?

I added the DUP to the end of the queue in the POST_MODULE, because the DUP needs EE components with the views already set (for an easy plugging of the concurrent context interceptor), and that seemed the safest place to put it into. Sincerely dunno if that's the best choice…