Community
Participate
Working Groups
Build Identifier: N/A. Affects EclipseLink 2.4.0-RC2 and 2.3.3-M3 If an application is deployed on JBoss AS 7.1.1.Final using EclipseLink (2.4.0-RC2 at least), entity classes aren't discovered by EclipseLink at runtime and the app won't work unless each class is enumerated by <class/> elements in persistence.xml . EclipseLink is deployed as a JBoss AS 7 module. <exclude-unlisted-classes>true</exclude-unlisted-classes> doesn't cause the classes to be discovered. I suspect this is a classloader issue; EclipseLink may not be getting the right classloader or looking on the correct classloader for entity classes for annotated entities. I don't know EclipseLink's innards well enough to be sure what's going on. A test case is attached that demonstrates the issue. Related issues are: https://bugs.eclipse.org/bugs/show_bug.cgi?id=383199 https://bugs.eclipse.org/bugs/show_bug.cgi?id=365704 Reproducible: Always Steps to Reproduce: 1. Download and unzip JBoss AS 7.1.1.Final 2. Download and unzip the test case 3. Read the README and comments for details
Created attachment 217680 [details] Test case showing problem may not be fixed in 2.4.0-RC2 and 2.3.3-M3
The article https://community.jboss.org/wiki/HowToUseEclipseLinkWithAS7 contains the statement: "You also need to explicitly list all of your entity classes, if you are not currently doing that, as EclipseLink is unable to auto-detect entity classes. This appears to be caused by the fact that EclipseLink doesn't know how to handle JBoss's virtual filesystem. It appears that custom implementations of org.eclipse.persistence.jpa.Archive and ArchiveFactory would be needed to fix this, but no one has yet attempted to write them." suggesting that this issue may not be ClassLoader related after all.
More detail from Scott Marlow, and an example of how it's done elsewhere: https://community.jboss.org/message/737795#737795
A workaround by Rich DiCroce now exists, see https://community.jboss.org/wiki/HowToUseEclipseLinkWithAS7 . It's included in my integration bundle library as linked on https://bugs.eclipse.org/bugs/show_bug.cgi?id=383201 .
I admit not to have looked deeply at the issue related to the archiving, but I wonder if it is potentially a container issue with JBoss. The spec states that the PersistenceUnitRootURL should be set up as follows: * Returns the URL for the jar file or directory that is the * root of the persistence unit. (If the persistence unit is * rooted in the WEB-INF/classes directory, this will be the * URL of that directory.) * The URL will either be a file: URL referring to a jar file * or referring to a directory that contains an exploded jar * file, or some other URL from which an InputStream in jar * format can be obtained. * @return a URL referring to a jar file or directory If JBoss is giving us something that cannot be decomposed using standard Java File or JarFile objects, the issue may be in the container.
Filed JBoss issue AS7-5062 on this topic; it does seem odd that EclipseLink would need an adapter to scan classes given http://docs.oracle.com/javaee/6/api/javax/persistence/spi/PersistenceUnitInfo.html#getPersistenceUnitRootUrl() . https://issues.jboss.org/browse/AS7-5062 I'll have a look soon (it's late, so not today) and see what's actually passed right now and what EclipseLink does with it.
JBoss AS 7 is indeed not providing a resolvable URL to the deployment. Here's an example from an Arquillian unit test: vfs:/content/8744d775-9837-4a5f-b1ab-22259f7e19b6.war/WEB-INF/classes/ It's a URL object, but the scheme isn't something EclipseLink will be able to do anything with without help. AS7 can provide a custom archive factory to allow EclipseLink to cope with such URLs, and that's what the new support code is doing. What AS7 is doing would seem questionable in standards terms though. The spec says the URL must be a file: schema URL, or must be some other URL resolvable to a jar. This is neither; it's a vfs:/ url to (in this case) the class-root of an exploded jar. The URL object has an assigned handler of type org.jboss.vfs.protocol.VirtualFileURLStreamHandler If AS7 insists on doing something funky, I tend to think it's AS7's problem to make it work. An custom archive factory set globally as a system property seems like the way to do that.
It's increasingly looking like JBoss AS 7's VirtualJarInputStream isn't behaving how EclipseLink expects. See detail on https://issues.jboss.org/browse/AS7-5062 . I suspect that EclipseLink will perform better when JBoss AS 7 provides it with an archive adapter, but it should really work out of the box if AS7's virtual file system implementation behaves.
Thanks for looking at this. Please let us know how we can help.
Hi, I just wanted to point out that the WildFly 8 testsuite has https://github.com/wildfly/wildfly/blob/master/testsuite/compat/src/test/java/org/jboss/as/test/compat/jpa/eclipselink/EclipseLinkSharedModuleProviderTestCase.java using the suggested archive adapter solution. Also see documentation here https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-UsingEclipseLink which mentions that the "eclipselink.archive.factory" system property will need to be set.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
