I really like the idea of default instances that would be consistent with
other resource types in EE 7 as Anthony pointed out. For the majority of
apps, this would provide a simple, zero-configuration way to use
ManagedExecutorService/ScheduledExecutorService/ContextService/ThreadFactory
that is easily and straightforwardly overridable by the deployer. Writing
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 standardize a minimum set of contexts that must be
propagated by the default instances, provided the container supports those
contexts. Naming/classloader/security as mentioned previously would make
sense.
I would prefer that we not take the approach of having annotations that
define new instances, which in the case of
@ManagedExecutorService/_at_ManagedScheduledExecutorService results in a
proliferation of separate thread pools across applications. I would
prefer not to see applications managing their own thread pools, but in the
cases where it truly is necessary, the ability to use ThreadFactory (and
ContextService) with the Java SE executors already allows for that.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Frederick W Rowe/Raleigh/IBM_at_IBMUS
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 11/28/2012 07:14 AM
Subject: [jsr236-experts] Re: Feedback
All,
Wrt to Adam's comments and Anthony's responses/questions.
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 are mandatory:
JNDI name: 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:
2.3.1.1 Optional Contextual Invocation Points
...
Configuration option Callback-Context is available in
ManagedExecutorService and
...
should state:
...
Configuration option Contextual-Callback is available in
ManagedExecutorService and
...
Regards,
Fred Rowe
WebSphere Architect
Senior Software Engineer
IBM Software Group
frowe_at_us.ibm.com
Anthony Lai <anthony.lai_at_oracle.com>
11/27/2012 04:48 PM
Please respond to
jsr236-experts
To
jsr236-experts_at_concurrency-ee-spec.java.net, Adam Bien
<abien_at_adam-bien.com>
cc
Subject
[jsr236-experts] Re: Feedback
Hi Adam,
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:
@MailSessionDefinition( name="java:app/mail/MySession",
host="somewhere.myco.com", from="some.body_at_myco.com")
For example, a ManagedExecutorService could be defined by something like
@ManagedExecutorService (name="java:comp/env/concurrent/executor1",
context="all", threads="3")
Comments are welcome.
Regards
Anthony
On 10/16/12 12:46 PM, Adam Bien wrote:
HI *,
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.
Please see my comments in the PDF,
thanks!
adam