jsr236-experts@concurrency-ee-spec.java.net

[jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead

From: Binod <binod.pg_at_oracle.com>
Date: Fri, 08 Mar 2013 10:03:25 +0530

On Friday 08 March 2013 01:42 AM, Nathan Rauh wrote:
> Binod,
>
> ManagedScheduledExecutorService inherits from ManagedExecutorService,
> so a ManagedScheduledExecutorService is also a ManagedExecutorService
> and can be used as both. You don't necessarily need two different
> JNDI names.
Even 236 doesn't necessarily need to define these interfaces separately,
right?

Given JSR 236 do have these interfaces defined separately, I thought it
should be
the decision of SIP Servlet EG to decide whether they should define one
or more JNDI names. What I don't understand is how does it break, JSR 236.
>
> While it's true that a resource-ref to vendor-specific jndiName
> approach doesn't break portability, it does make necessary a manual
> step for a deployer to bind all of these resource references. A step
> which the deployer could get wrong and mistakenly map to a different
> Managed[Scheduled]ExecutorService instance that completely ignores the
> SIP-specific execution property, causing concurrency to not be
> restricted to a single task using a particular SIP session at a time
> as you have asked for. That manual step, and the risk that comes with
> it, could be avoided, in a portable manner, if this instance, in a
> manner similar to the default instances provided by the container, had
> a default JNDI name, with which applications could then do something
> like,
> @Resource(lookup="java:comp/SIPManagedScheduledExecutorService")
> ManagedScheduledExecutorService sipExecutor;
> making it explicit that the application requires the SIP
> Managed[Scheduled]ExecutorService, and making it unnecessary for any
> manual intervention by the deployer.
I did understand the point you are making. Again, I thought, this should
be left
to the decision of SIP Servlet EG, unless it breaks 236 in some way.

Make sense?

thanks,
Binod.

>
>
> Nathan Rauh
> ____________________________________________
> Software Engineer, WebSphere Application Server
> IBM Rochester Bldg 002-2 C111
> 3605 Highway 52N
> Rochester, MN 55901-7802
>
>
>
> From: binod pg <binod.pg_at_oracle.com>
> To: jsr236-experts_at_concurrency-ee-spec.java.net
> Date: 03/07/2013 05:57 AM
> Subject: [jsr236-experts] Re: New ContextService API proposal from JSR
> 359 spec lead
> ------------------------------------------------------------------------
>
>
>
> Even the resource-ref/component specific JNDI name approach doesn't
> break portability.
> Also, I was hoping that the duty of restricting the number of MES is
> with the product
> rather than the specification.
>
> In any case, SIP will need to define two JNDI names, right? One for
> ManagedExecutorService
> and another for ManagedScheduledExecutorService.
>
> thanks,
> Binod.
>
> On 3/7/2013 4:15 AM, frowe_at_us.ibm.com wrote:
> > Absolutely, there are two reasons. One, it allows for portability but
> > more importantly, configuration by exception. In other words, if my
> > SIP application needs to lookup the SIP-specific MES, I can expect to
> > find it at the proscribed location in JNDI, if its not there, there's a
> > problem.
> > Two, there is a single jndi name because there is a single SIP-specific
> > MES. The intent of JSR236 was not to proliferate instances of MES in
> > the appserver as it makes it difficult to centrally manage thread
> > pooling.
>
>