After tracing into the deployment code, I believe I found the bug that caused this problem, at least for my case. My EAR contains a MDB and the persistence.xml file for configuring the EntityManager. Two classes are involved in this deployment problem: org.jboss.ejb3.EJBContainer and org.jboss.ejb3.mdb.MessagingContainer. The MessagingContainer is a subclass of the EJBContainer, it has a method with the signature: protected JMSProviderAdapter getJMSProviderAdapter(){...} It invokes the public InitialContext getInitialContext(){...} in the EJBContainer class to obtain a InitialContext object in order to lookup the JMS provider adapter object from the JNDI. At the end of the method, MessagingContainer closes the InitialContext object. In the previous implemention, the EJBContainer.getinitialContext() method returns a new InitialContext object everytime it is called. In version 4.2.2.GA, it returns the shared instance of InitialContext object defined in the class InitialContextFactory, whch is defined as static in the InitialContextFactory class. As you might already figure out at this point, the problem rises when a MDB is deployed. Because the MessagingContainer.getJMSProviderAdapter() method closes the InitialContext object, it nullify all internal properties of the shared instance of the InitialContext object. This shared InitialContext object is later used to deploy the persistence.xml file, which throws the NoInitialContextException exception. To overcome this problem before the official fix is out, I had to recompile the EJB3 deployment jar with the modified source. the patched class is attached in the next reply below. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4110302#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...