Hi Nathan,
This is fine. This has the advantage of allowing the caller to have more
control of what types of context to be propagated to the thread that
invokes the ManagedTaskListener methods.
If everyone agrees with the removal of CONTEXTUAL_CALLBACK, section
2.3.1 of the spec could be changed from:
By default, it is not required that container context be propagated to
the threads that invoke these methods. This is to avoid the overhead of
setting up the container context when it may not be needed in these
callback methods. Java EE Product Providers may provide configuration
option in ManagedExecutorService and ManagedScheduledExecutorService to
make these callback methods contextual invocation points. See sections
3.1.4.1 and 3.2.4.1. Execution property CONTEXTUAL_CALLBACK_HINT in
ManagedTask can also be used to request these callback methods to become
contextual.
Other callback methods run with an unspecified context, but can be made
contextual through the ContextService (see following sections), which
can make any Java object contextual.
to:
It is not required that container context be propagated to the threads
that invoke these methods. This is to avoid the overhead of setting up
the container context when it may not be needed in these callback
methods. These methods can be made contextual through the
ContextService(see following sections), which can make any Java object
contextual.
and all references to the attribute Contextual-Callback will be removed.
Regarding other issues that I raised in my earlier mail:
1) null interfaces to createContextualProxy
- It is probably not very useful to allow returning a contextual proxy
object that does not implements any interfaces, which would have no
proxy method to invoke. So given the choices between this or throwing
IllegalStateException, I would prefer throwing exception and the javadoc
for the methods could be updated to reflect this change:
|IllegalArgumentException
<
http://download.oracle.com/javase/6/docs/api/java/lang/IllegalArgumentException.html?is-external=true>|-
- if *the interfaces argument is null,* the instance does not implement
all the specified interfaces or there is not an accessible default
constructor.
2) Will be renaming USE_PARENT_TRANSACTION to USE_CALLER_TRANSACTION
3) Renaming CONTEXTUAL_CALLBACK_HINT to CONTEXTUAL_CALLBACK
Non-issue since we will be removing the property.
4) ManagedTaskListener: Consider passing the task to methods of
ManagedTaskListener.
Proposed changes to the ManagedTaskListener APIs with addition argument
for the task that was originally submitted:
void taskSubmitted(Future<?> future, ManagedExecutorService executor,
Object task)
void taskAborted(Future<?> future, ManagedExecutorService executor,
Object task, Throwable exception)
void taskDone(Future<?> future, ManagedExecutorService executor, Object
task, Throwable exception)
void taskStarting(Future<?> future, ManagedExecutorService executor,
Object task)
task - the task that was submitted
5) Should we use annotations instead of executionProperties?
Not making any changesfor this issue.
6) use CDI Events mechanism with using @Observes instead of
ManagedTaskListener interface
No feedback on this issue yet.
Regards
Anthony
On 2/6/13 11:27 AM, Nathan Rauh wrote:
> Sorry to bring this up so late, but it just occurred to me that
> CONTEXTUAL_CALLBACK is redundant with capability that's already
> available in JSR 236.
> In the case where a user wants to guarantee that methods of
> ManagedTaskListener or Trigger will run with context of the task
> submitter, they can accomplish the same via ContextService,
> For example,
>
> contextualListener =
> contextService.createContextualProxy(ManagedTaskListener.class,
> listener);
> contextualRunnable = ManagedExecutors.managedTask(runnable,
> contextualListener);
> managedExecutorService.submit(contextualRunnable);
>
> So we don't necessarily need a CONTEXTUAL_CALLBACKor @Contextual at all.
>
> Nathan Rauh
> ____________________________________________
> Software Engineer, WebSphere Application Server
> IBM Rochester Bldg 002-2 C111
> 3605 Highway 52N
> Rochester, MN 55901-7802
>
>
>
> From: Nathan Rauh/Rochester/IBM
> To: jsr236-experts_at_concurrency-ee-spec.java.net
> Date: 01/31/2013 04:01 PM
> Subject: Re: [jsr236-experts] Some feedback for discussion
> ------------------------------------------------------------------------
>
>
> Anthony,
>
> Here are my comments,
>
> 1) clarify the behavior when no interfaces is passed in to the
> createContextualProxy APIs that takes "Class<?>... interfaces"
> I agree it would be good to clarify.
> Here's a third option to consider -
> ContextService.createContextualProxy should be consistent with the
> behavior of java.lang.reflect.Proxy, on which it is also possible to
> invoke
> Proxy.getProxyClass(ClassLoader, interfaces...)
> and
> Proxy.newProxyInstance(ClassLoader, interfaces, handler)
> without any interfaces. In both cases, it appears that.
> java.lang.reflect.Proxy just returns a proxy class or proxy that
> doesn't implement any interfaces. So,
> ContextService.createContextualProxy could do the same.
> Otherwise, I'd vote for (b) IllegalArgumentException
>
> 2. I'm fine with renaming to USE_CALLER_TRANSACTION to make it clearer
>
> 3. I'm also fine with renaming to CONTEXTUAL_CALLBACK, and with the
> JavaDoc updates to clarify
>
> 4. ManagedTaskListener: Consider passing the task to methods of
> ManagedTaskListener. This sounds like it might be convenient, but if
> we do it, I'd prefer we add the task as its own parameter rather than
> change the first argument in the methods from Future to FutureTask.
> I'm not so comfortable with FutureTask here, because it creates some
> confusion about whether or not the FutureTask, if re-submitted, would
> inherit the ManagedTaskListener and execution properties of the
> original task (for example, would the FutureTask be a ManagedTask?).
> It also seems likely that a user might want to cast back to their own
> task interface, and FutureTask makes that impossible.
>
> 5. Should we use annotations instead of executionProperties? I would
> say no, because annotations don't fit very well with a number of usage
> patterns. For example, I should be able to submit any generic
> Runnable or Callable (it might even be from another vendor) with
> execution properties. I should be able to use
> managedExecutorService.invokeAll to submit multiple tasks at once,
> each with their own different execution properties. I should be able
> to write portable applications that include vendor-specific execution
> properties from multiple application server vendors. It's not clear
> to me where annotations would go that would cover all of these
> scenarios. I can see how @Contextual on ManagedTaskListener and
> Trigger would make sense rather than having CONTEXTUAL_CALLBACKas an
> execution property (and so I'm fine with just that), but I don't see
> how the other execution properties could be annotations and still
> preserve all the functionality that you get with the spec as currently
> written.
>
>
> 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/31/2013 01:13 PM
> Subject: [jsr236-experts] Some feedback for discussion
> ------------------------------------------------------------------------
>
>
>
> Dear Experts,
>
> I have received some feedback about the spec and the APIs. Please let
> me know what your opinions are on these 6 items.
>
> 1. ContextService: To clarify the behavior when no interfaces is
> passed in to the createContextualProxy APIs that takes "Class<?>...
> interfaces" as one of the arguments
> - We could either
> - a) treat this as legal and the ContextService implementation would
> find out the what interfaces that the object to have proxy created
> implements, or
> - b) throws exception, possibly IllegalArgumentException
>
>
> 2. ContextService: The name USE_PARENT_TRANSACTION is confusing.
> Consider renaming to USE_CALLER_TRANSACTION
> - This property is intended to run the proxy method under the same
> transaction on the thread of the caller who invokes the proxy method
> to be run on the same thread. The name USE_PARENT_TRANSACTION could
> lead users to think that the proxy method would be invoked under the
> transaction of the thread where the contextual proxy method was created.
>
>
> 3. ManagedTask: Consider renaming CONTEXTUAL_CALLBACK_HINT to
> CONTEXTUAL_CALLBACK
> - Reason being Java EE container are required to make the callback
> contextual if this property is set to "true" for a submitted task.
> Having "HINT" in the property name suggests that the Java EE container
> can choose not to make the callback contextual.
>
> - The javadoc for CONTEXTUAL_CALLBACK property would be
> Execution property to be returned in _getExecutionProperties()_
> <../../../javax/enterprise/concurrent/ManagedTask.html#getExecutionProperties%28%29>or
> _ContextService.createContextualProxy()_
> <../../../javax/enterprise/concurrent/ContextService.html#createContextualProxy%28T,%20java.util.Map,%20java.lang.Class%29>*to
> inform the Java EE Product Provider* about whether the methods
> in_ManagedTaskListener_
> <../../../javax/enterprise/concurrent/ManagedTaskListener.html>and
> _Trigger_
> <../../../javax/enterprise/concurrent/Trigger.html>associated with
> this task needs to be called under the same context as the task. Any
> values other than "true" means the methods will be run with
> unspecified context.
>
>
> 4. ManagedTaskListener: Consider passing the task to methods of
> ManagedTaskListener
> - The idea is to allow the applications to resubmit the task from
> ManagedTaskListener methods. ManagedTaskListener methods already
> passed in ManagedExecutorService as one of the arguments.
> - If we agree that this is a good idea, one possibility is to change
> the first argument in the methods from Future to FutureTask.
>
>
> 5. Should we use annotations instead of executionProperties?
> - For example, instead of using LONGRUNNING_HINT="true" and
> IDENTITY_NAME="some description", a task can be annotated with
> something like @LongRunning and @IdentityName(value="some description")
> - CONTEXTUAL_CALLBACK[_HINT] would become an annotation for the
> ManagedTaskListener implementation. For example @Contextual.
>
>
> 6. There is also a suggestion to use CDI Events mechanism with using
> @Observes instead of ManagedTaskListener interface for getting
> notified of task submission lifecycle callback.
>
> Comments are welcome.
>
> Regards
> Anthony