Skip to main content

Re: CDI scopes and SIP Servlets

  • From:
  • To:
  • Subject: Re: CDI scopes and SIP Servlets
  • Date: Mon, 31 Dec 2012 16:19:53 -0500


Hope everyone had a good holiday season.

Since CDI scoping is dependent on the thread local contexts, it seems that this discussion will some what hinge on how we decide to move forward on the concurrency discussions (and async context switching).  

I think its reasonable to assume we could find a way to support @SipApplicationSessionScoped, if we decide to always use an SAS to define the thread context on which SIP related processing happens (for both SIP container and non-container events). I'm having a harder time understanding how SipSessionScoped would work in this case because there can be many SipSessions involved with the processing of a single event. As stated below by Keith, there is no way currently to have multiple scoped instances associated with the same thread:

There may be no more than one mapped instance per contextual type per thread (6.3).

So maybe it does make sense to support @SipApplicationSessionScoped but not @SipSessionScoped? The decisions we make related to threading I think could have a profound affect on the CDI discussions. Because of this we may want to change the order of the F2F agenda to discuss threading before CDI.

I'm also struggling with use cases for @SipMessageScoped and @SipTransactionScoped that wont potentially become problematic because of the same issue. Since what you laid out in your original e-mail is not something CDI currently supports shouldn't we try to bound our discussions by what is currently supported by the CDI APIs?

Brian Pulito
WebSphere Architect - SIP
IBM WebSphere Development (Lexington)
Office  720-356-7964

From: Binod < >
To: ,
Date: 12/17/2012 12:39 AM
Subject: Re: CDI scopes and SIP Servlets

I am doing a POC on this at the moment targeting a presentation at F2F.
Will have a more informed response later. Here is my initial reaction.

If SIP Servlets support only Dependent and ApplicationScoped,
wont the CDI support be rather limited?

For example, ApplicationScoped is limited for having one instance per whole
application (more like a singleton). Dependent scope is a PseudoScope and the
instances are never shared. So, the use of such beans are very limited.

However, having SipMessageScoped/SipSessionScoped/SASScoped would
make a serious difference to the programmability and
extensibility of sipservlets.

Otherwise, I agree that making use of CDI observer methods and injection
of SIP built-in types are very useful.


p.s: gives some ideas to explore for
       solving our outbound context establishment issues.

On Saturday 15 December 2012 04:52 AM, George Vagenas wrote:

Binod, Lewis,

I agree with Lewis point that CDI contexts for sip messages, sip session and sip application sessions are less useful than the http equivalents and we can do without them.

From my experience with CDI and Sip Servlets, there are several benefits for the end user if we make use of CDI. For example the event notification model and the dependency injection can fit perfectly to the sip servlets programming model and simplify it a lot.

Portable extensions is a major concern also; using portable extensions users can create reusable components or provide extensions to integrate with other Java EE technologies. 

Here is an example of a POJO that makes use of dependency injection and event notification model: 

public class SimpleSipServlet {
private SipFactory sipFactory;

protected void doInvite(@Observes @Invite SipServletRequest req)

protected void doSuccessResponse(@Observes @SuccessResponse SipServletResponse resp)
{ ... }


On Fri, Dec 14, 2012 at 12:31 PM, Lewis, Keith < " target=_blank> > wrote:

I have been reading up on CDI and thinking through the issues you have raised.
I am not an expert and may be misunderstanding some aspects in what
follows. The section references below are to the final release CDI

CDI uses a client proxy object to provide a contextual reference to a
bean with normal scope (5,4). The client proxy is used to find the
appropriate bean instance whenever the bean is referenced. To do this
it needs to have a Context associated with the current thread. There
may be no more than one mapped instance per contextual type per thread

In a web container the request context and session context is created
before calling the service() method of a servlet (6.7.1, 6.7.2). The
context is populated with bean instances associated with the request
and session currently being serviced. This fits with the nature of
http servlets where the application only deals with one request and
one session during the whole of the execution of the service method.

A SIP application needs to interact with several different requests,
responses, sessions and application sessions during the execution of
the service method of a sip servlet. Messages can be created or
retrieved from session attributes, sessions and app sessions can be
looked up by id. This makes the notion of having CDI contexts for sip
messages, sip sessions and sip application sessions less useful that
the equivalents for http servlets.

There is no problem with being able to associate an application
context with the current thread in a SIP container prior to invoking
methods in a sip application. This means that we could allow
application scoped beans to be injected into sip servlets and
listeners and sucessfully interact with application scoped beans
during the execution of any servlets and listeners invoked by the SIP

Similarly there should be no problem with any beans that have a
dependent scope as long as their parents are application scoped.

Although we may choose not to provide CDI scopes for sip messages, sip
sessions and sip application sessions there are ways in which sip
servlets could make use of CDI, EJBs and ManagedBeans to provide a
similar capabilities. We should be able in a sip application to do the
following :-

1. Use JNDI to create an enterprise session bean and then store a
reference to it as an attribute of a sip message, sip session or sip
application session.
2. Use JNDI to create an instance of a bean annotated with
@ManagedBean and then store a reference to it as an attribute of a sip
message, sip session or sip application session.
3. Use CDI to inject a contextual reference to the SipFactory,
SipSessionUtil or TimerService into a managed bean, servlet or EJB.
4. Use CDI to fire events to observer methods on application scoped
beans or their dependent beans.

Keith Lewis
Thrupoint Ltd

On Tue, Dec 4, 2012 at 12:49 PM, Binod <
" target=_blank> > wrote:
> Hi everyone,
> I have been analyzing CDI for the use of SIP Servlets. To begin with, I looked
> at what scopes would make sense for SIP Servlets. Here is the list of scopes
> I came up with.
> @SipSessionScoped (equivalent to @SessionScoped)
> @SipApplicationSessionScoped
> @SipMessageScoped (equivalent to @RequestScoped)
> @SipTransactionScoped (if we decide to have a Transaction interface)
> CDI sort of assumes that the scopes are initialized as a message (eg: http)
> arrives in the container. However, in SIP Servlet programming, a scope context
> (eg: SipSession) may be created as part of an outgoing request and that session
> might be used for further incoming messages. And CDI does not appear to
> accommodate these use-cases well (correct me if I am wrong).
> ConversationScoped does not cover this outbound case either. Even the
> ConversationScope begins as a transient scope when a request is received
> in the container. It can later be upgraded to long running. From whatever
> I have read, it appear like there can be only one Conversation for a servlet
> request lifecycle.
> To model this correctly for SIP, I was thinking of a model of multiple conversations
> and associated sessions and sip application sessions. The thinking is to extend the
> model of javax.enterprise.inject.Instance to select the beans associated with a particular
> session/sas/transaction.
> <pseudo-code> //Not a proposal
> @SipApplicationSessionScoped
> public class B2b {
>   @Inject
>   Instance<B2bLeg> legs;
>   @Inject
>   SipServletRequest request;
>   @Inject
>   SipFactory factory;
>   @Inject
>   SipApplicationSession sas;
>   public B2bLeg createNewLeg() {
>     SipServletRequest otherLegRequest =
>     factory.createRequest(sas, request.getMethod(), request.getFrom(), request.getTo());
>     B2bLeg otherLeg =; //Not possible with CDI today
>     otherLeg.create();
>     return otherLeg;
>   }
> </pseudo-code>
> Do anyone know of accommodating this model with the existing CDI
> capabilities?
> thanks,
> Binod.

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. Thrupoint, Inc.

CDI scopes and SIP Servlets

Binod 12/04/2012

Re: CDI scopes and SIP Servlets

Binod 12/07/2012

Re: CDI scopes and SIP Servlets

Lewis, Keith 12/14/2012

Re: CDI scopes and SIP Servlets

George Vagenas 12/14/2012

Re: CDI scopes and SIP Servlets

Binod 12/17/2012

Re: CDI scopes and SIP Servlets

brian_pulito 12/31/2012
Please Confirm