3 Replies Latest reply on Feb 23, 2017 4:14 AM by Nuno Godinho de Matos

    Wildfly 10.0.0.Final - Sample War App - Using Eclipselink 2.6.4 - jar-file paths not properly handled

    Nuno Godinho de Matos Newbie

      Hi,

       

      I have just started a question

       

      Wildfly 10.0.0.Final - persistence.xml jar-file element not properly supported when using eclipselink - Stack Overflow

       

      I am struggling quite a bit with managing to get the jar-file element of the persistence.xml to work properly when using eclipselink together with wildfly 10.

      Even though hibernate is the default JPA provided wildfly, I would like to be able to use eclipselink as our application has primarily been tested against eclipselink.

       

      A trivial sample application is given that can demonstrate this issue:

      https://github.com/99sono/eclipselink-wildfly-jar-file-issue

       

      The sample application consits of a single startup EJB that when it is put to run it will try to create a database comprised of a single entity.

      The object is to make sure that the jar-file element is evaluated appropriately by the JPA provided and the JPA entity is descovered via jar-file scanning and not by class scanning.

       

      Is anyone aware of any bug of wildfly 10 integrating with eclipselink?

      Namely in regard  to the handling of these vfs paths that are used by wildfly?

       

      Kindest regards.

        • 1. Re: Wildfly 10.0.0.Final - Sample War App - Using Eclipselink 2.6.4 - jar-file paths not properly handled
          Nuno Godinho de Matos Newbie

          Hi,

           

          I have now seen that the archieve scanner used by hibernate in in widlfly comes from:

          jar:file:/C:/dev/Widlfly10/wildfly-10.0.0.Final/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/

          jipijapa-hibernate5-10.0.0.Final.jar!/org/jboss/as/jpa/hibernate5/HibernateArchiveScanner.class

           

          Could it be that wildfly has implemented such a scanning extension for eclipselink?

           

          <dependency>

              <groupId>org.wildfly</groupId>

              <artifactId>jipijapa-eclipselink</artifactId>

              <version>10.0.0.Final</version>

          </dependency>

           

           

          And I am now looking at the fact that wildlfy also offers a

           

                  <dependency>

                      <groupId>org.wildfly</groupId>

                      <artifactId>jipijapa-eclipselink</artifactId>

                      <version>10.0.0.Final</version>

                  </dependency>

           

           

          I have not looked at the source of this eclipsleink archieve, but My guess is that widlfly has implemented proper support for eclipselink, and there is only some module configuration that I must have incorrectly set when using eclipselink.

          Any pointers would be appreciated.

           

          Kind regards.

          • 2. Re: Wildfly 10.0.0.Final - Sample War App - Using Eclipselink 2.6.4 - jar-file paths not properly handled
            Nuno Godinho de Matos Newbie

            Hi,

             

            Just to report back - I was correct in my assumption that Jboss hs already created an eclipselink enhancement to deal with the virtual file system.

            The problem was that the wildfly configutation I was working on was probably created based on old wildfly documentation and it did not include as a resource the:

            Manve library as above.

             

            In addition the system property to tweak the eclipseli link archieve factory was not configured in the domain, so the default archieve factory of eclipselink was being used, which was incorrect.

             

            Sorry for the question ... this was a simple matter of someone configuring things based on stale documentation.

             

            Kind regards,

            Nuno.

            • 3. Re: Wildfly 10.0.0.Final - Sample War App - Using Eclipselink 2.6.4 - jar-file paths not properly handled
              Nuno Godinho de Matos Newbie

              One last point the relevant references for this are:

               

              1. JPA Reference Guide - WildFly 10 - Project Documentation Editor

               

              2. Module configuration as follows:

               

              <module xmlns="urn:jboss:module:1.1" name="org.eclipse.persistence">

                  <resources>

                      <resource-root path="jipijapa-eclipselink-10.0.0.Final.jar"/>

                      <resource-root path="eclipselink-2.6.4.jar">

                         <filter>

                            <exclude path="javax/**" />

                         </filter>

                      </resource-root>

                  </resources>

               

                  <dependencies>

                      <module name="asm.asm"/>

                      <module name="javax.api"/>

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

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

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

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

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

                      <module name="javax.xml.bind.api"/>

                      <module name="javax.ws.rs.api"/>

                      <module name="org.antlr"/>

                      <module name="org.apache.commons.collections"/>

                      <module name="org.dom4j"/>

                      <module name="org.jboss.as.jpa.spi"/>

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

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

                  </dependencies>

              </module>

               

              3. System property:

              <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>

               

              in the stand-alone,xml

               

              Works like a charm.