0

In wildfly 10.0.0.Final, eclipselink does not seem to be properly supported. Sure, hibernate is the default JPA provided for wildfly, but enabling eclipselink module is supported and using eclipselink is quite possible. However, the jar-file elements of a persistence.xml seem to resolve during runtime to some special wildfly vfs paths that hibernate can handle but eclipselink seems not to know how to handle.

From what I have been able to debug, and now being certain that my configuration is 100% correct. The configuration works for

  • wildfly + hibernate / jar-file element resolves to vfs:/ path during runtime
  • weblogic + eclipselink / jar-file element resolves to file:/ path durin runtime
  • widlfy + eclipselink / does not work - stuck with using <class> element

I am convinced that the root of the problem is that eclipselink is not prepared to deal with the wildfly special vfs (virtual file system) paths.

Although eclipselink is handling the exact same vfs paths as hibernate: - Hibernate scans the path and comes out finding entity classes - the other comes out empty handed.

I have put together the following sample application. https://github.com/99sono/eclipselink-wildfly-jar-file-issue

The application branches into two identical paths.

  • One for Weblogic,
  • the other for Wildfly.

The weblogic app can deploy perfectly. However, it can mostly be used to demonstrate how "un-nice" the jar-file element definition can be, depending on whether a person is: - deploying from eclipse (e.g. as exploded war) - or deploying as a real WAR application. This most likely boils down to a weblogic eclipse plugin bug, but well... it can be made to work. Namely, to make the code be able to deploy in both modalities, i was forced to use as jar-file, the non JEE spec compliant value of ../lib/entities.jar. this is explained in more detail in the app readme.

In any case, Weblogic has the great advantage here of using your usual file:/ urls, that eclipselink can handle perfectly. So there is a work-around here to this mixed relative-path parent folder behavior of weblogic, associated to how the app gets deployed.

The second application is for wildfly. This is where things get tough. In wildly, when we deploy an application and debug either Hibernate booting logic, or eclipselink booting logic, we see that a virtual file system (vfs) urls are being used. As said above, the vfs urls to the jar-files are identical for hibernate and for eclipselink.

If we deploy from eclipse, our projects are exploded. They are not deployed as real .jar files but into exploded directories.

If we deploy the real WAR file, on the other hand, using the management console, instead our paths refer to the wildfly bin directory. In this case, these paths are 100% virtualized directories that cannot be opened in our real file system. This contrasts to the scenario where we deploy from eclipse using jboss tools. The path to exploded direcotires can be opened in our file system.

What seems to happen in wildfly, is that: - while in both scenarios hibernate seems to be able to cope with whatever vfs path jar-file that comes its way - Eclipselink cannot.

The readme for the sample application provided gives some hints to some good classes for debugging the deployment.

Is anyone aware of a work-around to make the jar-file work to eclipselink?

Did I do something wrong in my persistence.xml for ecipselink, and eclipselink is prepared to handle the vfs of jboss?

At the current point in time the only thing that works properly is the <class>qualified</class approach, but of course this approach is borderline useless most of the time and just helps to create maintenance hell.

I would sincerely welcome any help on getting jar-file element to work properly with ecipselink 2.6.4 on wildfly 10.

I there any light at the end of the tunnel?

Kind regards

99Sono
  • 3,554
  • 27
  • 39

1 Answers1

0

THe issue is now addressed.

In fact the jar-file property is properly supported in wildfly 10. The issue I was experiencing was related to the fact that our eclipselink module configuration had been created based on out of date wildfly docuemntation, whereby wildfly at that point in time most likely had not yet invented the virtual file system and the jipijapa-eclipselink-10.0.0.Final.jar did not exist.

Once I saw the following hibernate cllass implementing the scanning: 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

And this hibernate class being owned by a jboss maintained jar, the next question is why not such a jar for eclipse link. Which indeed it does exist.

So the support for vfs file scanning is given by the following:

<dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>jipijapa-eclipselink</artifactId>
            <version>10.0.0.Final</version>
            <scope>provided</scope>
</dependency>

And all that one needs to do once the module configuration in the wildfly modules is appropriate is to induce eclipselink to use the jboss archieve factory:

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

This is all document in: https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-UsingEclipseLink

99Sono
  • 3,554
  • 27
  • 39