4 p.m.
Already had to move the DUP up to PARSE phase due to OSGi test issues
Eduardo Martins <emartins(a)redhat.com> wrote:
I opened https://github.com/wildfly/wildfly/pull/4705 , which provides both the JSR 236
a.k.a. EE Concurrent implementation and it's plugging into Wildfly EE subsystem. In a
first short summary this allows EE components to retrieve (through @Resource or JNDI
lookup) and use the specs default managed objects (managed executor services, managed
thread factory and managed context service).
There are still a few things to discuss, but let me first explain what's in the PR,
making life easier for the reviewer(s):
1) ee-concurrent module - the JSR 236 Impl.
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.
2) "concurrent" package in ee extension - the deployment unit processor, msc
services, jndi bindings and interceptors
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.
To discuss:
a) ee-concurrent + ee versus ee/extension + ee/concurrent?
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.
b) security context interceptor
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
c) More interceptors?
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?
d) DUP phase
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…
e) Go to the beach? It's touching 40ºC here lately!
--E