3 Replies Latest reply on Sep 13, 2017 1:32 AM by jaikiran

    EntityManager is null when injected in WildFly 10 EJB

    mikedevva

      I have been working on moving our application from JBoss AS 6 to Wildfly 10. The main problem I have been stuck on is that the EntityManager does not get injected into the EJB. I have been researching this for a while and trying everything I find but nothing helps.

       

      I don't have a simple application to recreate the problem yet but here are some details and snippets of code.

       

      We are deploying using a SAR file. This is a Spring framework application. Our second level cache is turned off for now. That's another problem I need to tackle.

       

      persistence.xml:

      <?xml version="1.0" encoding="UTF-8"?>
      <persistence xmlns="http://java.sun.com/xml/ns/persistence"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
                      http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
              version="1.0">
        <persistence-unit name="IpsDb" transaction-type="JTA">
          <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
          <jta-data-source>java:jboss/datasources/HarmonyServerDS</jta-data-source>
          <jar-file>../harmonyserver-model.jar</jar-file>
          <properties>
            <!-- pessimistic lock timeout in milliseconds (Integer or String), this is a hint used by Hibernate but requires support by your underlying database. -->
            <property name="javax.persistence.lock.timeout" value="15000"/>
            <!-- query timeout in milliseconds (Integer or String), this is a hint used by Hibernate but requires support by your underlying database --> 
            <property name="javax.persistence.query.timeout" value="15000"/>
            <property name="hibernate.transaction.jta.platform" value="org.hibernate.service.jta.platform.internal.JBossStandAloneJtaPlatform" />
            <property name="hibernate.cache.use_query_cache" value="false"/>
            <property name="hibernate.cache.use_second_level_cache" value="false"/>
          </properties>
        </persistence-unit>
      </persistence>
      

       

       

      Beginning of the datasource from standalone-full.xml:

      <datasource jta="true" jndi-name="java:jboss/datasources/HarmonyServerDS" pool-name="HarmonyServerDS" enabled="true" use-java-context="true" spy="false" use-ccm="true" connectable="false">
      

       

      From the EJB class (These are the important parts but not all of the code from the class):

      @Stateless
      @Clustered
      public class DataModificationBean implements DataModificationLocal {
      
          @PersistenceUnit(unitName="IpsDb")
          private EntityManagerFactory entityMgrFactory;
      
          @PersistenceContext(unitName="IpsDb")
          private EntityManager entityMgr;
      
          @Override
          @Transactional(propagation=Propagation.REQUIRES_NEW)
          @InterruptOnTransactionTimeout(value=true)
          public DataModificationResponse handleModification(DataModification mod, ModificationHandler handler, AdaptationContext adaptation, boolean bulk_lock)
          {
              try {
                  // Handler's data update monitor for delta changes. 
                  DataUpdateMonitor updateMonitor = null;
                  
                  // Pre-process the request and gather up the dataContext for processing.
                  logger.info("DataModificationBean EntityMgr=" + (entityMgr == null ? "null" : entityMgr.toString()));
                  logger.info("DataModificationBean EntityMgrFactory=" + (entityMgrFactory == null ? "null" : entityMgrFactory.toString()));
                  handler.preProcess(this, entityMgr);
      

       

      The logging at the bottom of that snippet shows that the entityMgr and entityMgrFactory are null.

       

      Is there something else I'm missing? Or anything else I could show that would be helpful?

        • 1. Re: EntityManager is null when injected in WildFly 10 EJB
          jaikiran

          Given what you state, there's more than one thing you might have to take care of:

           

          1. SAR is no longer recommended for WildFly (I don't remember if there's any real support for that packaging which was specific to JBoss AS). So move it to proper Java EE packaging, which can be either a EJB jar or a web application (WAR) or a EAR, depending on your application needs.

           

          2. How are you looking up and invoking this stateless bean from the client? Can you post that code?

          • 2. Re: EntityManager is null when injected in WildFly 10 EJB
            mikedevva

            Your second question pointed me to what I was missing. I had to change JNDI bean names from what I guess was an old format to the new format. I had changed some of these but not the one for this bean. The bean wasn't found from the context so a new one was created in the code. We have this code in there only for test cases but I didn't notice that was what it was doing. Now that I fixed the JNDI name, the bean is found and the EntityMgr gets injected.

             

            But I have one question. Do you know of any documentation that states that SAR files are not recommended? We have been wondering about this but haven't found anything. And we don't want to switch the file type yet if we don't have to.

            • 3. Re: EntityManager is null when injected in WildFly 10 EJB
              jaikiran

              Michael Feldman wrote:

               

               

               

              But I have one question. Do you know of any documentation that states that SAR files are not recommended? We have been wondering about this but haven't found anything. And we don't want to switch the file type yet if we don't have to.

              I looked around a bit in the official documentation to see if there's a word about this, but I couldn't find any. When I was part of the WildFly team, we had discussed this internally and we considered the SAR deployment packaging as just a feature that's only there to support backward compatibility with older versions of the server. If someone from the current WildFly team confirms this, then you can consider it official.