Thanks for the feedback.|
If nobody objects, I can start working on adding default instances
support for MES, MSES, ContextService, and MTF.
Agree that Naming, classloader, and security are good candidates as
standard context. We can use these as the set of default set of
contexts to be propagated.
To clarify "Container Context", how about rewriting this paragraph
in section 2.3
"The contexts to be
propagated are governed by the container but typically include
naming context, class loader and security information."
"The contexts to be propagated includes naming context, class
loader, and security information. Container must support propagation
of these context types. In addition, containers can choose to
support propagation of other types of context."
Regarding the issue of requiring JSR 236 objects to be bound to the
java:comp/env/concurrent subcontext. I checked with Linda, the spec
lead for Java EE 7, and she says that is not consistent with the
other resource types. So I suggest that we should keep it as a
About defining resources via annotations. Looks like we don't have
an agreement yet. Let's see if we get more feedback from other
On 11/28/12 7:36 AM, Nathan Rauh wrote:
type="cite">I really like the
idea of default instances
that would be consistent with other resource types in EE 7 as
out. For the majority of apps, this would provide a simple,
way to use
is easily and straightforwardly overridable by the deployer.
this up would just involve copying from EE 7 section 5.20
or 5.21 and replacing
with the JSR
236 resource types, but on top of that I would recommend that we
a minimum set of contexts that must be propagated by the default
provided the container supports those contexts.
as mentioned previously would make sense.
I would prefer that we not take
approach of having annotations that define new instances, which
case of @ManagedExecutorService/@ManagedScheduledExecutorService
in a proliferation of separate thread pools across applications.
would prefer not to see applications managing their own thread
in the cases where it truly is necessary, the ability to use
(and ContextService) with the Java SE executors already allows
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
11/28/2012 07:14 AM
Wrt to Adam's comments and Anthony's responses/questions.
3. The terminology of the original comment is somewhat
"start with the injection of plain Executor services managed by
container." Isn't a plain Executor service managed by the
simply a ManagedExecutorService? Is the proposal that the scope
the JSR be reduced to simply supporting MES? I think MES by
is useful without ContextService ONLY if there is a standard set
propagated by default. This goes back to my proposal earlier
year to make MES required and the other three APIs optional.
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
for that section to address any shortcomings. As mentioned
however, there is not yet a general consensus of a finite set of
so it is possible that simply listing all of the contexts
to the EG is the best we can do.
5. The comment: "We should reduce optional things. E.g. jndi
etc.", is misleading, JNDI names are mandatory:
but required, name to identify the service instance. The
value to map the service to the component’s resource environment
What is not mandatory is the namespace into which they are
the proposal is to require the use of a specific namespace
I'm ok with that.
I think that defining annotations for the managed objects is a
and fairly easy to do. Does someone want to make a proposal of
those would look like?
Separate from that discussion, please correct the following
in the document:
188.8.131.52 Optional Contextual Invocation Points
Configuration option Callback-Context is available in ManagedExecutorService
Configuration option Contextual-Callback
is available in ManagedExecutorService and
Senior Software Engineer
IBM Software Group
11/27/2012 04:48 PM
Please respond to
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?
container inject some default instance similar to the "default
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
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
could be propagated, such as naming context, class loader,
is up to the container to decide what context to be propagated.
this falls into the same issue as your next point about reducing
things. Perhaps we should identify the common context and
I think JNDI and security would be the candidates.
I would think transaction is typically not one of the context to
5. Reduce optional things
You suggested that we should require, instead of just recommend,
to be bound in the java:comp/env/concurrent subcontext. I saw a
in the Java EE spec that tends to provide recommendation instead
when it talks about binding of particular types of objects into
subcontext. Should we follow that convention? Are there any
making it an requirement to bind JSR 236 objects into
Your other suggestion is to remove all examples of configuration
and select a few to become standard configuration attributes. I
should do this. Any suggestions on which attributes we should
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
JSR 236 objects?
There are annotations in the Java EE 7 spec for defining various
of resources. Taking an example from section 5.19.6 in the Java
a mail session resource can be defined on a container-managed
using this annotation:
For example, a ManagedExecutorService could be defined by
Comments are welcome.
On 10/16/12 12:46 PM, Adam Bien wrote:
I read the proposal and probably found some problems /
(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
should work without any XML configuration.
3. I would reduce the scope and start with the injection of
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
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
to mandatory services, and discuss the optional things later.
Please see my comments in the PDF,