I created a simple project using Eclipse which when built, has the following structure:
The entities.jar file contains a simple JPA entity `test.MyEntity` annotated with @Entity. The persistence.xml contains `<jar-file>META-INF/entities.jar</jar-file>` which, according to JPA 2.1 secifications pages 366-368 (http://download.oracle.com/otn-pub/jcp/persistence-2_1-fr-eval-spec/JavaPersistence.pdf) should scan the META-INF/entities.jar file which is in the same directory as the META-INF/persistence.xml. The underlying database is a simple HSQL db (just for the sake to have a database in the persistence.xml properties).
The application simply loads the persistence-unit:
public class MyMainClass {
public static void main(String[] args) {
EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("test-hibernate2" );
}
}
When run on Hibernate 5.0.2.Final, the following stacktrace is obtained (i.e. the latest Hibernate version is also impacted by this issue):
One workaround is to have a custom Scanner class which manages the relative URLs and absolutize them. I copied the AbstractScannerImpl source code into test.MyCustomScanner, added the constructors of StandardScanner, and added the following code in the environment.getNonRootUrls() loop:
if (!url.getPath().startsWith("/")) {
try {
URL absoluteUrl = new URL(environment.getRootUrl(),url.getPath());
url=absoluteUrl;
} catch (MalformedURLException e) {
throw new RuntimeException("cannot make the relative URL as absolute:"+url);
}
}
The spirit is the same as Lauri Harpf's pull request (https://github.com/hibernate/hibernate-orm/pull/889/files), but with the priority given to the relative URL and using a relative URL test instead of an exception catching mechanism.
The risk with this approach is that all non root URLs are managed the same way, not only the ones of `<jar-file>` tags. Thus, side effects may appear. The custom scanner is then added to the persistence.xml:
When run, the execution log shows no exception and only raises a concern that `MyEntity` table does not exist, which shows that the entities.jar has been processed correctly:
While the workaround is pretty simple, it may serve to people that are "impatient" to see issue HHH-4161 solved.
|