Wrt to Adam's comments and Anthony's
3. The terminology of the original
comment is somewhat confusing: "start with the injection of plain
Executor services managed by the container." Isn't a plain Executor
service managed by the container simply a ManagedExecutorService? Is
the proposal that the scope of the JSR be reduced to simply supporting
MES? I think MES by itself is useful without ContextService ONLY
if there is a standard set of contexts propagated by default. This
goes back to my proposal earlier this year to make MES required and the
other three APIs optional. The problem with the default propagation
of contexts is that we never got enough feedback on the discussion started
by Nathan on an earlier thread of what that set of contexts was.
4. The comment: "Often mentioned
"Container Context" is not clearly defined." The intent
of section 2.3, Container Thread Context, is to define that, please
make specific change proposals for that section to address any shortcomings.
As mentioned above however, there is not yet a general consensus
of a finite set of contexts, so it is possible that simply listing all
of the contexts currently known to the EG is the best we can do.
5. The comment: "We should reduce
optional things. E.g. jndi names etc.", is misleading, JNDI names
The arbitrary, but required, name to identify the service instance. The
deployer uses this
value to map the service to the
component’s resource environment reference.
What is not mandatory is the namespace
into which they are bound. If the proposal is to require the use
of a specific namespace subcontext (like java:comp/env/concurrent),
I'm ok with that.
I think that defining annotations for
the managed objects is a good idea and fairly easy to do. Does someone
want to make a proposal of what those would look like?
Separate from that discussion, please
correct the following inconsistency in the document:
18.104.22.168 Optional Contextual
Invocation Points ...
Configuration option Callback-Context
is available in ManagedExecutorService
Configuration option Contextual-Callback
is available in ManagedExecutorService
Senior Software Engineer
IBM Software Group
Anthony Lai <
11/27/2012 04:48 PM
Please respond to
Adam Bien <
[jsr236-experts] Re: Feedback
1. DI of resources
Thanks for pointing this out. I have fixed the incorrect usages of DI in
the Early Draft.
2. Injection without XML confiuguration
Which instance should be injected without any configuration? Should the
container inject some default instance similar to the "default Data
Source" and "default JMS Connection" mechanism as described
in sections 5.20 and 5.21 in the Java EE 7 spec?
3. Reduce the scope and start with the injection of plain Executor services
What do other experts feel about reducing the scope?
4. "Container Context" not clearly defined
The spec provides examples of what are the possible container context that
could be propagated, such as naming context, class loader, security. It
is up to the container to decide what context to be propagated. I guess
this falls into the same issue as your next point about reducing optional
things. Perhaps we should identify the common context and standardize them.
I think JNDI and security would be the candidates.
I would think transaction is typically not one of the context to be propagated.
5. Reduce optional things
You suggested that we should require, instead of just recommend, that resources
to be bound in the java:comp/env/concurrent subcontext. I saw a few examples
in the Java EE spec that tends to provide recommendation instead of requirement
when it talks about binding of particular types of objects into specific
subcontext. Should we follow that convention? Are there any problems with
making it an requirement to bind JSR 236 objects into java:comp/env/concurrent?
Your other suggestion is to remove all examples of configuration attributes,
and select a few to become standard configuration attributes. I think we
should do this. Any suggestions on which attributes we should consider
to be standardize?
Furthermore, suppose we have defined a set of required attributes and their
possible values, would it be useful to provide annotations for defining
JSR 236 objects?
There are annotations in the Java EE 7 spec for defining various types
of resources. Taking an example from section 5.19.6 in the Java EE spec,
a mail session resource can be defined on a container-managed class by
using this annotation:
For example, a ManagedExecutorService could be defined by something like
Comments are welcome.
On 10/16/12 12:46 PM, Adam Bien wrote:
I read the proposal and probably found some problems / inconsistencies
(or completely misunderstood that :-)).
I incorporated the comments into the PDF--see attachment.
Summary of my comments:
1. DI of resources into manually created tasks won't work, or has to be
performed by the pools. We should clarify that.
2. We should rely more on Convention over Configuration. It means: injection
should work without any XML configuration.
3. I would reduce the scope and start with the injection of plain Executor
services managed by the container. It would already solve about 80% of
challenges from my projects.
4. Often mentioned "Container Context" is not clearly defined.
I guess TX are not covered by the definition. Otherwise a in EJB initiated
TX could be propagated into an asynchronous task...
5. We should reduce optional things. E.g. jndi names etc. should be mandatory--otherwise
the suggestions are worthless. I would reduce the scope of the whole spec
to mandatory services, and discuss the optional things later.