users@concurrency-ee-spec.java.net

[jsr236-spec users] [jsr236-experts] Re: Public Review started!

From: Anthony Lai <anthony.lai_at_oracle.com>
Date: Fri, 11 Jan 2013 15:30:49 -0800

Agree.

Regards
Anthony

On 1/11/13 3:21 PM, Nathan Rauh wrote:
> 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>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto: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_
> <mailto: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_
> <mailto:users_at_concurrency-ee-spec.java.net>
> mailing list.
>
> Regards
> Anthony
>
>
>