Anthony,
That's an interesting question about a "false" value.
Intuitively, I'd interpret CONTEXTUAL_CALLBACK_HINT=false to mean "don't
run the callbacks with any context", but I can't see why anyone would care
to require that behavior, because if they don't care about using the
context, then unspecified is even better because unspecified doesn't
require the container to do any work swapping context off/back on the
thread.
Maybe the best approach would be to omit "false" as an option altogether
altogether, and only allow "true" or unspecified.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 01/11/2013 04:54 PM
Subject: [jsr236-experts] Re: Public Review started!
Thanks Nathan.
Good point. Just want to clarify,
No CONTEXUTAL_CALLBACK_HINT: unspecified context
CONTEXUTAL_CALLBACK_HINT = "true": same context as task
Should CONTEXTUAL_CALLBACK_HINT = "false" implies unspecified context
too?
Will fix the minor typos too. Thanks for catching them.
For 3.1.1.1.7, the constructor call is taking advantage of type inference
for generic instance creation in JDK 7 so we have left out "<String,
String>".
Regards
Anthony
On 1/11/13 11:26 AM, Nathan Rauh wrote:
Anthony,
I reviewed the spec and the JavaDoc again and it looks very good. I
spotted one issue and a couple of minor typos, which I'll list here.
Section 2.3.1.1 is inconsistent with ManagedTaskListener and Trigger APIs
regarding whether, by default, listener/trigger methods run in the same
context as the task.
2.3.1.1 Optional Contextual Invocation Points
The following callback methods are not contextual invocation points by
default, but may be configured as
contextual invocation points if desired:
javax.enterprise.concurrent.ManagedTaskListener
* taskAborted()
* taskSubmitted()
* taskStarting()
javax.enterprise.concurrent.Trigger
* getNextRunTime()
* skipRun()
....
javax.enterprise.concurrent.ManagedTaskListener JavaDoc API:
"Each listener method will run with the same context in which the task
runs. "
javax.enterprise.concurrent.Trigger JavaDoc API:
"Each method will run with the same context in which the task runs. The
Trigger becomes a Contextual Task "
I would say that neither of the above (Spec nor JavaDoc) has the most
desirable behavior. Because context propagation is costly, we should
allow for the container implementation to do the most efficient thing in
the default case: not having to remove any context that's already present
and not having to add any context that isn't already present. Whenever
there are cases where the application cares one way or the other about
whether callback points are contextual, the application should specify the
CONTEXTUAL_CALLBACK_HINT to guarantee the desired behavior.
I would propose that we make the following changes, to make the Spec and
JavaDoc consistent, and allow flexibility to the container.
2.3.1.1 Optional Contextual Invocation Points
The following callback methods run with unspecified context by default,
but may be configured as
contextual invocation points if desired...
javax.enterprise.concurrent.ManagedTaskListener JavaDoc API:
"Each listener method will run with unspecified context unless
CONTEXTUAL_CALLBACK_HINT is specified to control whether or not these
callback methods run under the context in which the task runs. "
javax.enterprise.concurrent.Trigger JavaDoc API:
"Each method will run with unspecified context unless
CONTEXTUAL_CALLBACK_HINT is specified to control whether or not these
methods run under the context in which the task runs. The Trigger becomes
a Contextual Task "
Minor typos:
Section 3.1.1 and Section 3.2.1:
java.enterprise.concurrent.ManagedTaskListener
should be
javax.enterprise.concurrent.ManagedTaskListener
Section 3.1.1.1.7:
execProps = new HashMap<>();
should be
execProps = new HashMap<String, String>();
Sections 3.1.8.2, 3.2.8.2, 3.3.5.2 and 3.4.6.2:
javax.sql.Connection
should be
java.sql.Connection
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 01/04/2013 03:07 PM
Subject: [jsr236-experts] Public Review started!
Dear experts,
The Public Review Draft has been posted on
http://jcp.org/aboutJava/communityprocess/pr/jsr236/index.html
Public review period will end on Feb 4. Please send any feedback to the
jsr236-experts_at_concurrency-ee-spec.java.net mailing list. Readers not on
the expert group can send feedback to users_at_concurrency-ee-spec.java.net
mailing list.
Regards
Anthony