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_CALLBACK or @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_CALLBACK as 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() or
ContextService.createContextualProxy() to inform the Java EE Product
Provider about whether the methods inManagedTaskListener and Trigger
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