Skip to main content

Re: Public draft Section 23.4

  • From: Keith Lewis < >
  • To: jsr359-experts < >
  • Subject: Re: Public draft Section 23.4
  • Date: Tue, 11 Feb 2014 12:41:39 +0000

Additional responses in purple.

Keith Lewis


On 11 February 2014 11:29, Binod 
< >
 wrote:

>  Hi Keith,
> Please see the comments (red color) below.
>
>
> On Monday 10 February 2014 07:59 PM, Keith Lewis wrote:
>
> Comments below in blue.
>
>  Keith Lewis
>
>
> On 10 February 2014 09:53, binod pg 
> < >
>  wrote:
>
>>  Hi Keith,
>>
>>
>> On 2/6/2014 6:27 PM, Keith Lewis wrote:
>>
>>  23.4.3.1 specifying app name
>>
>>  This facility duplicates what is available using the @Resource
>> annotation with a lookup element (or lookup-name in the DD). It does not
>> seem appropriate to use @Inject to access an object instance that cannot be
>> located using a CDI context. EE 5.24 seems to indicate that this should not
>> be done :-
>>
>> Containers must support injection points annotated with the
>> javax.inject.Inject annotation only to the extent dictated by CDI.
>>
>>
>>  In case of normal bean injection by the application, the semantics are
>> defined by CDI specification. The specifications may define built-in beans
>> which
>> may have additional semantics.
>>
>> I remember we discussing these in F2F and the course of discussion was,
>> we should not use @Named built-in qualifier, since it
>> is already have semantics specified by CDI specification and hence will
>> use our own annotation. So, we wanted to define a different
>> annotation to specify this.
>>
>> If we need to mention any thing about the lifecycle of the built-in
>> beans, we can do that. For example, making it explicit that these
>> beans are passivation capable dependencies.
>>
>>
>  The way to get a reference to ServletContext of a different WAR achive
> is by using JNDI. It seems an abuse of the @Inject annotation to use it to
> do that JNDI lookup - @Resource is the appropriate annotation for that.
>
>
> JNDI lookup, @Resource and @Inject are used interchangeabley in many
> specifications.
>

Yes they can be interchanged when the JNDI context is java:comp/env since
that is resolved using data associated with the current thread. We are
talking here about resources from the JNDI context java:app


> IMHO using a @Inject instead of @Resource is perfectly fine.
>
>

>  When @Inject is used on any of the SIP specific CDI beans a client proxy
> will be injected as described in 5.4 of the cdi spec. It is only when a
> method is invoked on the built in bean that the contextual instance will be
> found (usually via a ThreadLocal on the current thread). There can only be
> one instance of a contextual type per thread. There doesn't seem to be a
> way in CDI to implement what our spec describes.
>
>
> Contextual Proxies are used only when  the scope of the bean is a normal
> scope.
> CDI also support pseudo-scopes which allows a direct injection of the
> object.
> So, it should be possible to inject the built-in beans correctly. I can
> check with
> RI team and get back to you on this, if you like.
>
>
Our built-in beans ARE normal scope - hence my comment.

>
>>  23.4.4 and 23.4.5
>>
>>  It would be more accurate to refer to the invocation of the
>> TimerListener rather than ServletTimer.
>>
>>
>>  Yep, right. Fixed it.
>>
>>
>>  Normal scoped contexts should also be provided for the doBranchResponse
>> method of a servlet.
>>
>>
>>  There is a bit of issues with doBranchResponse. May be we can discuss
>> this on wednesday in the meeting.
>>
>>
>>  The text about concurrency utilities in 23.4.4, 23.4.5.1, 23.4.5.2 and
>> 23.4.5.3 would be better moved to a section which is common to all normal
>> scopes. The text as it is written promises too much - the ContextService
>> which underlies all the concurrency utilities copies some or all of the
>> context from the calling thread so a particular context type is available
>> if (a) it was present in the original thread and (b) the ContextService is
>> configured to copy that context.
>>
>>
>>  Sorry, did not understand:  The current text only says that the context
>> is active when the task is being executed. What exactly you mean by
>> "promises too much"?
>>
>>   23.4.5.1 says that the application session context WILL be active
> given the specified conditions. That would only be true if the thread that
> made the call to the concurrency utility had an app session context. The
> concurrency utilities copy contexts from the current thread. So the
> conditions given are not enough.
>
>
> <snip>
> If the application session is specified programmatically as specified in
> section 18.3.2.1 Specifying Application Session Programmatically then the
> container will
> activate the relevant application session context.
> </snip>
>
> The above sentence points to the section 18.3.2.1 that specifies how an
> application
> session can be programmatically specified as the context while submitting
> the task.
> This is by execution properties. Even in that case CDI context can be
> activated by the
> SIP container.
>
> I am referring to the previous sentence :-

Whenever a CDI bean is submitted as a task to the ManagedExecutorService or
ManagedSchduledExecutorService provided by the SIP servlet container (as
specified in section 18.3.2.5 Default Managed Objects) the application
session context will be active during each execution of that task.

>
>  The current text also adds unnecessary conditions - the task submitted
> does not need to be a CDI bean for the context to be active. In the case of
> the ContextService it does not even have to be a task.
>
>
> You have a point about ContextService, that we need to mindful of. I will
> take care of that in the next update.
>
> But on CDI beans, if the task is not a CDI bean, how would the
> CDI context will be useful? Injection will not happen on a normal
> callable, right?
>
> Yes you are correct that the context is more easily used if the task is a
CDI bean.
This text is the place where we formally define the contact that the
container must provide to applications. The container MUST setup the
context whether the task is a bean or not. Introducing irrelevant
conditions may result in containers which do not properly implement the
feature.

thanks,
> Binod.
>
>
>>  23.4.5.2 - Invocation Context
>>
>> I don't recall this ever being discussed by the EG. Lets check that there
>> is consensus about including it.
>>
>>
>>  Lets discuss on wednesday in the meeting.
>>
>>
>>  23.4.5.3 - Application Chain Context lifecycle
>>
>> There are lots of issues with this scope. I think this content has been
>> added to the public draft prematurely we should only include it if it has
>> had adequate discussion and receive wide support. We would prefer to see it
>> proposed in a separate document and then later included in the spec when we
>> have reached agreement. That is what has been done with other non trivial
>> proposals.
>>
>> A more powerful way of sharing state between applications is to add a
>> custom header to the SIP message.
>>
>>
>>  Lets discuss on wednesday meeting.
>>
>> - Binod.
>>
>>
>>     Keith Lewis
>>
>>  --------------------
>>
>> Note: The information contained in this message may be privileged and
>> confidential and protected from disclosure. If the reader of this message
>> is not the intended recipient, or an employee or agent responsible for
>> delivering this message to the intended recipient, you are hereby notified
>> that any dissemination, distribution or copying of this communication is
>> strictly prohibited. If you have received this communication in error,
>> please notify us immediately by replying to the message and deleting it
>> from your computer.  Thank you.  CafeX Communications.
>>
>>
>>
>
>  --------------------
>
> Note: The information contained in this message may be privileged and
> confidential and protected from disclosure. If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and deleting it
> from your computer.  Thank you.  CafeX Communications.
>
>
>

-- 


--------------------

Note: The information contained in this message may be privileged and 
confidential and protected from disclosure. If the reader of this message 
is not the intended recipient, or an employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify us immediately by replying to the message and deleting it 
from your computer.  Thank you.  CafeX Communications.


Public draft Section 23.4

Keith Lewis 02/06/2014

Re: Public draft Section 23.4

binod pg 02/10/2014

Re: Public draft Section 23.4

Keith Lewis 02/10/2014

Re: Public draft Section 23.4

Binod 02/11/2014

Re: Public draft Section 23.4

Keith Lewis 02/11/2014

Re: Public draft Section 23.4

binod pg 02/18/2014

Re: Public draft Section 23.4

Keith Lewis 02/20/2014

Re: Public draft Section 23.4

binod pg 02/21/2014
 
 
Close
loading
Please Confirm
Close