I like this idea. We could also use this mix-in interface to provide
hints for distributed execution, as tracked by jira issue 14.
But this seems to tightly couple the task implementation with the
ManagedTaskListener implementation. Suppose an application developer
schedules a task which is provided by some library but needs to monitor
the task using a ManagedTaskListener that he/she writes. Is this a valid
use case and do we need to worry about such scenarios?
Regards
Anthony
On 12/7/12 11:52 AM, Nathan Rauh wrote:
> The proposal about ManagedTaskListener is also interesting because I
> remember in one of the posts (which we never really addressed) where
> someone asked about specifying context properties on tasks submitted
> to a managed executor service. That's a very similar scenario in that
> it would also require additional method signatures.
>
> I gave some more thought to whether there are any other alternatives,
> and I think a better alternative than what I mentioned previously
> could be a mix-in interface that provides a getManagedTaskListener.
> We already have Identifiable being used here as a mix-in interface.
> We could convert Identifiable into something more general, say
> ManagedTask, and then add a getManagedTaskListener (and possibly also
> a getContextProperties) to it.
>
> So the idea here would be to replace
> javax.enterprise.concurrent.Identifiable
> .getIdentityName()
> .getIdentityDescription(Locale)
> with
> javax.enterprise.concurrent.ManagedTask
> .getIdentityName()
> .getIdentityDescription(Locale)
> .getManagedTaskListener()
> .getContextProperties() ?
>
> and then we could meet the request of removing all of the method
> signatures on ManagedExecutorServce/ManagedScheduledExecutorService
> which copy from ExecutorService/ScheduledExecutorService without
> introducing the unpredictable behavior that would be introduced by
> ManagedExecutorService.add/removeManagedTaskListener.
>
> 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: 12/06/2012 02:53 PM
> Subject: Re: [jsr236-experts] On ManagedTaskListener related APIs in
> MES and MSES
> ------------------------------------------------------------------------
>
>
> Anthony,
>
> I agree with your concerns about what happens when multiple
> applications register listeners to the same managed executor service.
> I think it would cause too much unexpected behavior, and we should
> not switch to add/removeManagedTaskListener.
>
> The only other alternative I can think of for avoiding the
> ManagedTaskListener copies of the method signatures is to allow for
> submitted tasks to optionally implement ManagedTaskListener, but that
> would be kind of awkward and would seem to make taskStarting/taskDone
> notifications redundant with the beginning and end of the run/call
> method.
>
>
> 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: 12/05/2012 04:42 PM
> Subject: [jsr236-experts] On ManagedTaskListener related APIs in MES
> and MSES
> ------------------------------------------------------------------------
>
>
>
> Dear experts,
>
> There is recently a suggestion on the MES and MSES APIs that I would
> like to get opinions from the expert group.
>
> The idea was instead of having 7 new APIs in the ManagedExecutorService
> and 4 in ManagedScheduledExecutorService whose only difference from the
> ones in the super class in java.util.concurrent package was the addition
> of an extra parameter for ManagedTaskListener, could we replace them
> with an addTaskListener and removeTaskListener to the
> ManagedExecutorService interface?
>
> Pros:
> - Much fewer new APIs in MES and MSES
> - Easier to register same ManagedTaskListener to monitor events for all
> task submissions. For example, an application can register a single
> ManagedTaskListener to an MES receive all events related to task
> submissions.
>
> Cons:
> - Becomes awkward when need to specify a different ManagedTaskListener
> for each task submission
> - Management of list of task listeners, especially if the MES is shared
> across multiple applications and that applications that registers the
> listener may be undeployed.
>
> I tend to prefer the current APIs, but I would like to bring this up and
> see if anyone have different opinions or suggestions.
>
> Regards
> Anthony
>
>