Tossing about injecting SipServlet SipFactory into JavaEE 6 Bean

After several days, I finally learned a lot about Least-intrusive and Most-portable. The following is a special example.

Let's talk about it first: I don't know why the domestic JavaEE 6 Information is at least. This is what Gavin King (Hibernate, Seam leader) Strongly recommends, and is already comparable to Spring, especially CDI ). In the future, add some links to this statement .)

Basic Environment: Mobicents SipServlet 3.0.0-Snapshot, JBoss AS 7.13, JavaEE 6

Requirement: Use JavaEE6 technology to reconstruct a VOIP project based on Mobicents. This article only shares the experience of using annotations of CDI and EJB3.1 to implement dependency injection. Otherwise, you need to repeat it later.

Q: How can I easily inject a versatile SipFactory into a common beanCDI management) or an EJB3.1 bean?

Try 1: directly @ Resource.

public class MySipServlet extends SipServlet {    @Resource private SipFactory sipFactory;    ...}@Singletonpublic class MyBean {    @Resource private SipFactory sipFactory;}

Result: injection is successful in SipServlet (MySipServlet. In general, (MyBean) cannot be injected successfully, and sometimes NPE exists.

Analysis: after arduous investigation and evidence collection, I think I found some reasons... according to the official statement of Mobicents, SipFactory is built only when the Context of the SipServlet container is started, and the SipServlet container is started with the initialization of the first SipServlet. Note that Lazy Loading is used by default ). This means that even if the above MyBean is Stateless, when SipFactory needs to be injected and used, it is not ready yet! Even if there are three methods to obtain the JNDI call, mappedName, and @ Resource), the above problem still cannot be solved. Especially if you need to add @ Startup to a @ Singleton, The SipFactory is not ready after it is instantiated.

Attempt 2: Based on the above analysis, you can only discard the above three methods. Next, we naturally want to listen to the SipServletContext event and wait for it to initialize SipFactory.

public class SipServletFacade1 implements SipServletListener {    private SipFactory sipFactory;}public class SipServletFacade2 extends SipServlet implements SipServletListener {    private SipFactory sipFactory;}

Result: SipServletFacade1 seems very simple, but it seems that the container implemented by Mobicents does not accept that only SipServlet can be used as SipServletListener ?), So it fails. SipServletFacade2 is too invasive. SipServlet should be on the presentation layer rather than on the business layer!

Analysis: We have noticed the idea of Facade mode and Event/Listener. We want to use the Facade in POJO mode to encapsulate the SipServlet container tool class SipFactory. On the one hand, it shields its dependency injection method, and on the other hand, there are other advantages of Facade: such as simplicity and practicality, encapsulation exceptions, and so on. Unfortunately, the above method does not work...

Final attempt: JavaEE 6 is coming! Javax. enterprise. event. * saved us!

Analysis: the use of Event/@ Observes of JavaEE 6 greatly simplifies the implementation of the listener mode and reduces the injection performance. Low coupling is achieved.

public class MySipServlet extends SipServlet() {@Resource SipFactory sipFactory;@Inject private Event<MyEvent> myEventEmitter;...@Overridepublic void init() {    myEventEmitter.fire(new MyEvent(sipFactory));}public class SipServletFacade {    private SipFactory sipFactory;    public void sipServletInit(@Observes MyEvent myEvent) {        sipFactory = myEvent.getSipFactory();    }}

This article from the "I advise tiangu shake again" blog, please be sure to keep this source http://waynecui.blog.51cto.com/8231128/1329253