Skip to main content

Re: CDI and interworking with other protocols

  • From: "Lewis, Keith" < >
  • To: jsr359-experts < >
  • Subject: Re: CDI and interworking with other protocols
  • Date: Wed, 13 Feb 2013 09:21:43 +0000

Binod,

In response to your question below.

My aim was to allow the developer of a SIP application to expose an API which could be used from other containers/protocols. It seems reasonable to require that this API be expressed in terms of Java interfaces.

In a clustered environment there may be an RMI call required to access a SAS. This means that the beans used by the interworking proxy should be limited to a well designed high level API that can work will a small number of method calls. There may be a case for explicitly marking the interfaces of this API with an annotation similar to @Remotable for EJBs.

The calling application will often be in a separate war file and so be using a different classloader. Having an explicit API means that only the interface classes and a fixed set of value classes need to be made available to the calling application. The classes implementing beans can be located in the SIP sar or war file.

We may want to expand the use cases to ones where SIP processing switches from one SAS to another. Even here it would be good to limit the methods called to a limited set of high level methods on specific beans.

We could relax the restriction and use byte code generation libraries to create a dynamic subclass of the bean instead of a dynamic proxy. I don't think this is justified for the reasons given above.

Keith

On Wed, Feb 13, 2013 at 5:01 AM, Binod < " target="_blank"> > wrote:
Keith,

How would dynamic proxy work for all legal and proxy-able CDI bean types?

For example, a concrete class is a proxyable bean type in CDI. That
wouldn't work if a container use java.lang.reflect.Proxy, right?

thanks,
Binod.

On Tuesday 12 February 2013 11:17 PM, Lewis, Keith wrote:
Binod,

I haven't had time to look at this in detail.

The basis would be a dynamic proxy that wraps a CDI bean reference.
We wouldn't need to duplicate the CDI proxy functionality.

I was thinking that we could get a bean reference from the BeanManager as I explained to George:
Set<Bean<?>> beans = beanManager.getBeans(ELname);
Bean<?> target = beanManager.resolve(beans);
This target could then be used by our proxy. Here is a skeleton

public class InterworkingHandler implements java.lang.reflect.InvocationHandler {
        private static ClassLoader sipClassLoader;
        private final Object target;
       
        public static Object createProxy(Object target, Class<?> interfaceClass) {
            InvocationHandler handler = new InterworkingHandler(target);
            return Proxy.newProxyInstance(sipClassLoader, new Class<?>[] { interfaceClass },
                                          handler);
        }
       
       
        public InterworkingHandler(Object target) {
            this.target = target;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

            // Retrieve SAS context and associate with current thread

            Object result = method.invoke(target, method, args);

            // remove association with current thread

            return result;
  }


It would be possible to use Qualifiers as you say. I don't have any example code for that. It sounds like it might be cumbersome but we could have it as an extra set of overloaded methods.

Keith


On Tue, Feb 12, 2013 at 12:09 PM, Binod < " target="_blank"> > wrote:
Keith,

From an implementation perspective, how would the interworking
proxy be implemented? Do you see SIP containers implement the
same proxy implementation mechanism like what CDI does? A
simple dynamic proxy is not going to work here.

https://community.jboss.org/blogs/stuartdouglas/2010/10/12/weld-cdi-and-proxies?_sscc=t


Section 5.3 of the CDI spec says the following.

<code>
An EL name resolves to a bean if:
• the bean has the given bean name, and
• the bean is available for injection in the war containing the JSP or JSF page with the EL _expression_.
 </code>

Look like the EL names are generally meant for JSP or JSF applications.
IMO, use of EL names as a way to access beans from normal Java code is, at best,
a work around.

Have you considered a way to use qualifiers instead (I know this has been
asked before). For example, a model similar to
http://docs.jboss.org/cdi/api/1.0/javax/enterprise/inject/Instance.html
would help in using qualifiers instead of EL names?

thanks,
Binod.


On Friday 08 February 2013 10:29 PM, Lewis, Keith wrote:
All,

attached is an updated version of my CDI proposal which addresses the concerns and errors which George highlighted.

Keith

On Mon, Jan 28, 2013 at 12:43 PM, Lewis, Keith < " target="_blank"> > wrote:
George,

thank you for your comments.

Firstly regarding the example, it would have been better as you say if I had shown an example which used a SAS scoped bean. I will create an better example and repost the document.

What the example does show is injection of the current SipApplicationSession as a built-in bean.
This can be seen below where the appSession field is injected with the SipApplicationSession.

@ApplicationScoped @Named(“outgoingCallBean”)
public class OutgoingCallFacade implements OutgoingCall {
   @Inject
   private SipApplicationSession appSession;

I believe that this reference to the SAS is implemented using a CDI proxy that looks up the SAS CDI context when it is referenced.This will only work if there is a SAS CDI context - so it served as an example of some code which would only work if there was a current context associated with the thread.

I could equally have shown a SAS scoped bean that was injected into the application scoped bean. Or I could have shown a SAS scoped bean that was invoked directly.

Regarding the operation of the interworking proxy your description is not what I was trying to describe.
I was modelling the actions on what I think a web container would do in associating a http session context with a thread. Here are some points to note
  1. If the SAS already exists it will have a CDI context which may have been populated with some bean instances. If is is new it will have a context that only contains the built-in bean for the SAS.
  2. What the interworking proxy does is to locate this existing context and associate it with the current thread (e.g. by storing a reference to it in a thread local variable).
  3. If there is no instance of the named bean in this context then one will be created and added.
  4. In step (4) the proxy does not destroy the context it just removes the association between the context and the current thread (e.g. by setting the vale of the thread local variable to null).
So the bean instance that is used may be an existing one that for the current SAS - it is not always a new one. I hope that what I am describing is just the way that all CDI scopes work.

Regarding the operation of "getExportedBean" I said that it would "lookup the bean in the CDI application scope". I now realise that the method should be able to access the bean in any currently available scope - so it could be a ApplicationScope or a SipApplicationScoped bean. In terms of the BeanManager interface I think it would do the following :-
Set<Bean<?>> beans = beanManager.getBeans(ELname);


Bean<?> target = beanManager.resolve(beans);
// create an interworking proxy that wraps the bean 
I will correct the document to correct the mistake.

Regarding the use of qualifiers instead of EL names that would be possible, they seem to be clumsy to create programmatically, however, so I thought that the EL name was more convenient. We could create some example code for both methods to see how it looks.

Hope this helps.

Keith


On Thu, Jan 24, 2013 at 1:14 PM, George Vagenas < " target="_blank"> > wrote:
Hi all,

Keith, what confuse me is that you mention that for a SAS scope "it is required that we associate a SAS context with the current thread before executing any code that references a SAS scoped bean" and then you mention that the "getExportedBean method would lookup the bean in the CDI application scope". Similarly the code snippet you provided at the third page, the bean is annotated with @ApplicationScope. What is the SAS scoped bean in the given example?

To me, we would like to define a sip specific CDI contexts in order to have a well-defined life-cycle and visibility of the beans that belong to this context.

Can you please elaborate why we will define the SipApplicationSessionScope but have beans in the ApplicationScope?

If the intention is to have beans also defined in the SipApplicationSessionScope, then following are my comments.

From your description of how the proposed proxy object should work, (1) SAS context is populated (2) an instance of the bean is looked up in this context (3) invoke target method (4) SAS context is removed. 
From that i can conclude that:
  • step (2) will always return a new instance of the bean
  • SAS context life-cycle is similar to Dependent context
  • Bean instance life-cycle will also be similar to any bean with Dependent context
So to my understanding, for any invocation of the proposed proxy object, a new SAS context and a new bean instance will be created. I can't see the difference between the propose solution and the Dependent scope? 

An alternative to the proposed solution could be a bean at Dependent scope that a converged application can inject. Then using SipSessionUtils and SipFactory the application can associate the bean's method invocation with the appropriate SipApplicationSession.

A CDI context defines the life-cycle and visibility of instances of all beans with that scope. So by having SipApplicationSessionScope users might be misguided that bean instances belonging to that context will have the life-cycle of the SipApplicationSession and also that these bean instances could share their state. But this is not true since beans instances will be removed after the method invocation and are not bound into the SipApplicationSession lifetime.

Also a less important comment. I would suggest to minimize the use of the @Named(String) annotation since its not a typesafe approach. Instead qualifiers should be encouraged whenever possible.

Regards
George



On Tue, Jan 22, 2013 at 6:27 PM, Lewis, Keith < " target="_blank"> > wrote:
Hi all,

I have been thinking about the challenge of providing a mechanism for contextual CDI scopes.
I attach a proposal that would give us a SipApplicationSession scope.
It addresses interworking with other protocols since this is the main challenge we would need to overcome.

The document makes reference to the proposal for changes to JSR236 as I understand it.
I think my proposal would provide a better API for developers but that may be because I have misunderstood the JSR236 thing.

I have also been working on some sample code for the B2BUA scenario but that is not ready yet.

Keith
 
--------------------
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.




 
--------------------
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.





 
--------------------
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.





 
--------------------
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.






Re: CDI and interworking with other protocols

Lewis, Keith 02/08/2013

Re: CDI and interworking with other protocols

Binod 02/12/2013

Message not available

Message not available

Re: CDI and interworking with other protocols

Lewis, Keith 02/13/2013

Re: CDI and interworking with other protocols

Binod 02/13/2013

Re: CDI and interworking with other protocols

George Vagenas 02/13/2013

Re: CDI and interworking with other protocols

Lewis, Keith 02/18/2013
 
 
Close
loading
Please Confirm
Close