12 Replies Latest reply on Mar 6, 2015 4:40 PM by lujop

    JPA entity classes residing in a Wildfly module are not scanned

    marcos_aps

      I have some JPA entity classes residing in a Wildfly module. Although there are entity classes in this module, there's no JPA deployment descriptor (persistence.xml file) in the module. Here's the complete path of the module:

       

      {Wildfly_installation}/modules/system/layers/base/br/edu/ufca/main/ufca.jar


      The module descriptor (located in the same folder):


      <?xml version="1.0" encoding="UTF-8"?>

      <module xmlns="urn:jboss:module:1.3" name="br.edu.ufca">

        <resources>

        <resource-root path="ufca.jar"/>

        </resources>

        <dependencies>

        <module name="javax.faces.api"/>

        </dependencies>

      </module>


      Now I have a web application where I declare the dependency on this module in META-INF\MANIFEST.MF:


      Manifest-Version: 1.0

      Class-Path:

      Dependencies: br.edu.ufca export


      I also have, in the web application, the persistence.xml file where I list some entity classes that are located in the ufca.jar module:


      <?xml version="1.0" encoding="UTF-8"?>
      <persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" version="2.1">
      <persistence-unit name="criacao-email">
        <jta-data-source>java:jboss/datasources/CriacaoEmailDS</jta-data-source>

       

        <class>br.edu.ufca.modelo.Setor</class>

        <!-- more classes -->

       

      </persistence-unit>
      </persistence>


      The problem is that when I run the web application executing code that tries to load some entity classes using an EntityManager, for example, I get exceptions like this:


      Caused by: java.lang.IllegalArgumentException: org.hibernate.hql.internal.ast.QuerySyntaxException: Setor is not mapped [SELECT s FROM Setor s ORDER BY s.nome]

      at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1750) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1683) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:331) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]

      at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:443) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]

      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]

      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]

      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]

      at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]

      at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

      at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

      at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

      at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

      at org.jboss.weldx.persistence.EntityManager$911040993$Proxy$_$$_Weld$Proxy$.createQuery(Unknown Source) [hibernate-jpa-2.1-api-1.0.0.Final.jar:]

      at br.edu.ufca.criacaoemail.negocio.CriadorEmailSetorial.localizarSetores(CriadorEmailSetorial.java:28) [classes:]

      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]

      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]

      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]

      at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]

      at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

      at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)

      at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]

      at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]

      at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

      at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)

      at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

      at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.1.0.Final.jar:8.1.0.Final]

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

      at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]

      at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

      at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]

      ... 122 more

      Caused by: org.hibernate.hql.internal.ast.QuerySyntaxException: Setor is not mapped [SELECT s FROM Setor s ORDER BY s.nome]

      at org.hibernate.hql.internal.ast.QuerySyntaxException.generateQueryException(QuerySyntaxException.java:96) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.QueryException.wrapWithQueryString(QueryException.java:120) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:234) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:158) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:126) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:88) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:190) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:301) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:236) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1800) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:328) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]

      ... 168 more

      Caused by: org.hibernate.hql.internal.ast.QuerySyntaxException: Setor is not mapped

      at org.hibernate.hql.internal.ast.util.SessionFactoryHelper.requireClassPersister(SessionFactoryHelper.java:189) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.ast.tree.FromElementFactory.addFromElement(FromElementFactory.java:109) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.ast.tree.FromClause.addFromElement(FromClause.java:95) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.ast.HqlSqlWalker.createFromElement(HqlSqlWalker.java:331) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.fromElement(HqlSqlBaseWalker.java:3633) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.fromElementList(HqlSqlBaseWalker.java:3522) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.fromClause(HqlSqlBaseWalker.java:706) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:562) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:299) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:247) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:278) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:206) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]

      ... 176 more


      which clearly shows that the JPA provider didn't scan the entity classes. But if I access from the web application any class from the Wildfly module without using JPA, I have success, which shows that the module is really in the classpath of the application.

       

      Is this default behaviour or what am I doing wrong?

       

      Thank you in advance.

       

      Marcos

       

      PS.: Cross-posted: http://stackoverflow.com/questions/26404069/jpa-entity-classes-residing-in-a-wildfly-module-are-not-scanned

        • 1. Re: JPA entity classes residing in a Wildfly module are not scanned
          ctomc

          You are missing jandex index for your jpa jar.

          • 2. Re: Re: JPA entity classes residing in a Wildfly module are not scanned
            marcos_aps

            Tomaz Cerar escreveu:

             

            You are missing jandex index for your jpa jar.

            I updated the dependencies of my module. It now looks like this:

             

            <dependencies>

                <module name="javax.faces.api"/>

                <module name="org.jboss.jandex"/>

            </dependencies>

             

            But I'm still getting the same error as if the classes were not scanned.

             

            Marcos

            • 3. Re: Re: JPA entity classes residing in a Wildfly module are not scanned
              smarlow

              Why do you have entity classes in a module?  Are you trying to share the same set of classes between multiple applications that will not have those same entity classes?

              • 4. Re: JPA entity classes residing in a Wildfly module are not scanned
                marcos_aps

                Scott Marlow escreveu:

                 

                Why do you have entity classes in a module?  Are you trying to share the same set of classes between multiple applications that will not have those same entity classes?

                 

                Exactly.

                • 5. Re: Re: JPA entity classes residing in a Wildfly module are not scanned
                  smarlow

                  I think that Tomaz suggested that you ensure that you have run the "jandex" maven/ant/whatever build task against your module jar.  Have you looked into that yet?

                   

                  https://github.com/jipijapa/jipijapa/blob/master/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/VirtualFileSystemArchiveDescriptor.java could really use some TRACE logging to show what is scanned in the deployment.  I don't think that we will scan entity classes in the module classpath but the only way to verify is either debugging or adding TRACE logging.

                  • 6. Re: Re: Re: JPA entity classes residing in a Wildfly module are not scanned
                    marcos_aps

                    Scott Marlow escreveu:

                     

                    I think that Tomaz suggested that you ensure that you have run the "jandex" maven/ant/whatever build task against your module jar.  Have you looked into that yet?

                     

                    https://github.com/jipijapa/jipijapa/blob/master/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/VirtualFileSystemArchiveDescriptor.java could really use some TRACE logging to show what is scanned in the deployment.  I don't think that we will scan entity classes in the module classpath but the only way to verify is either debugging or adding TRACE logging.

                     

                    I don't use Ant or Maven in my web application. I just use Eclipse. As I said I can access the entity classes in my web application. If I write a code like this one:

                     

                    Setor setor = new Setor();

                     

                     

                    It doesn't give me any error at runtime, which shows that the wildfly module was loaded and is in my application classpath. On the other side, I know that the persistence provider isn't scanning the entities in the module because I get errors like this:

                     

                    Caused by: org.hibernate.hql.internal.ast.QuerySyntaxException: Setor is not mapped


                    when I try to access the Setor class using the EntityManager or Query, which shows that the Setor class is not mapped (it wasn't scanned).


                    Can't we have JPA entity classes in a Wildfly module because they won't be scanned?


                    Marcos

                    • 7. Re: Re: Re: JPA entity classes residing in a Wildfly module are not scanned
                      smarlow

                      I don't expect that the persistence provider will scan all classes on the application classpath.  The scanning for entities is done via the PersistenceUnitInfo.getPersistenceUnitRootUrl()

                       

                      Do you have a specific reason for sharing the entity module between deployments?  I am curious if there is some pain, that you are addressing with this approach? 

                      • 8. Re: JPA entity classes residing in a Wildfly module are not scanned
                        marcos_aps

                        Scott Marlow escreveu:

                         

                        I don't expect that the persistence provider will scan all classes on the application classpath.  The scanning for entities is done via the PersistenceUnitInfo.getPersistenceUnitRootUrl()

                         

                        Do you have a specific reason for sharing the entity module between deployments?  I am curious if there is some pain, that you are addressing with this approach?

                        I wouldn't get to the point to call it a pain, but I can tell you a situation that I would like to avoid: imagine that I have three web applications that make use of my jar file that has the entity classes. The jar file is, in this case, in the WEB-INF/lib folder of all three web applications. I also have one or more ear archives with the same jar file there somewhere. If I change some entity class or any other class in this shared jar, I have to update all web applications and the ear archives with the jar new version. I can even forget to update one of them or more. After that I have to deploy all of them as well. If my entity classes where in a Wildfly module you know that I wouldn't have all this trouble because all I had to do was to update the module. In my opinion, I think this is a reasonable thing to do or am I missing something?

                         

                        I just would like to have a final answer about this issue, if there's a way to have my entity classes in my Wildfly module scanned or if this is really forbidden?

                         

                        Thank you.

                         

                        Marcos

                        • 9. Re: JPA entity classes residing in a Wildfly module are not scanned
                          smarlow

                          The static WildFly module will not be scanned for entity classes, as it will not be in the persistence unit root url (url for the root of the persistence unit).  Static WildFly modules are also not deployed, so I think you would have to restart the app server to hack in new entity classes.

                           

                          Would deploying the three web applications in exploded form. allow you to share a common file via an operating system symbolic link (e.g. via linux "ln" command)?  I'm not sure but you might be in a better position to try and let us know what happens.  Obviously, you would want to use a symbolic link for the shared jar containing the entity classes.  See some documentation here about configuring auto-deploy-exploded.  If you go this path and update the shared entity jar, I'd expect the three war applications to undeploy/redeploy.  I see no reason why this wouldn't work but still think you will want to test it (could be some edge case that I don't know about).

                           

                          If anyone else has feedback, please share.  :-)

                           

                          Scott

                           

                          • 10. Re: JPA entity classes residing in a Wildfly module are not scanned
                            marcos_aps

                            I think that I will abandon the idea of making the jar where the entity classes reside a Wildfly module, given the difficulties of making it work. I just don't understand why this restriction regarding the scanning of the entity classes in modules. It seems natural that it should work. Maybe someone can explain it to me. The symbolic link idea could work, but I would like a simpler one. I will stick placing the jar in the WEB-INF/lib folder for the time being. It's a pity that it can't be done as I expected. If there are any other alternative I would like to know. Thank you for the help, Scott.

                            • 11. Re: JPA entity classes residing in a Wildfly module are not scanned
                              smarlow
                              I just don't understand why this restriction regarding the scanning of the entity classes in modules. It seems natural that it should work. Maybe someone can explain it to me.

                              The persistence provider currently expects to resolve entity classes via the persistence unit url(s)).  Think about the persistence provider opening up your war file and walking through the war to check each contained class if it is an entity class.

                               

                              I agree that a simpler solution would be better than using symbolic links.  Perhaps some type of shell script that handles a entity jar change (build the jar, update the three wars + ear, then deploy them.) 

                              1 of 1 people found this helpful
                              • 12. Re: JPA entity classes residing in a Wildfly module are not scanned
                                lujop

                                Did you found any workarround on this or you abandoned the idea of having the JPA classes in a module?

                                 

                                In our case we migrate from Jboss 4.2.3 where we used a global shared EntityManager with the PU inside.

                                And an ideal solution will be to reproduce that. Because we have 3 versions of the PU that only differs with the Hibernate Dialect and we have dozens of independent apps/ejbs that use the model.

                                That way, in 4.2.3 we provide the needed JPA/PU jar in global namespace for the installed database and we don't need to make different versions of the other apps for database vendor.

                                Any suggerence or workarround in sharing the JPA/PU between unrelated projects?

                                 

                                A lot of thanks in advance,