JAR-packed entities?

[nickarls]

Hi,

   Are there any known issues (or tricks) with the jar-file-element in persistence.xml with AS 7.1.1? I tried picking up entities from a jar in my war lib but fail to do so.

Thanks in advance,

  Nik

[jaikiran]

Can't recollect of any issues. What problem are you running into?

[nickarls]

I have a war with entities.jar in the lib. The war has a persistence.xml with <jar-file>entities.jar</jar-file>. On PC-usage, I get an exception for a missing named query (defined in an entity in the jar). 

[matthiaskrebs23]

I have a similar problem( jboss-as-7.1.1, im trying to use a persistence unit in an test setup outside of the entity jar in an arquillian / shrinkwrap setup.

<persistence-unit name="testdb">

     <jar-file>entites.jar</jar-file>

      ...

</persistence-unit>

* this did not worl inside an arquillian ear deployment in jboss7. (jboss concurrent classloader ?)

* this does work when used in ant with hbm2ddl ("normal" java classloader)

what did work:

* i generated hbm.xml from the entities

* i put the hbm files into the test.ear

    test.ear

    ---hbm\*hbm.xml

* <jar-file>file:/hbm/</jar-file>

The persitennce unit / classloader was able to find the entities  / files.

The same problem seem to exist with hibernate property hibernate,hbm2ddl.import_files, the classloader is not able to find 'import.sql', no matter where placed.

It looks like the ConcurrentClassloader does some filtering which prevents him from finding 'regular' files ?

org.hibernate.tool.hbm2ddl.SchemaExport.execute(Target output, Type type) calls

   InputStream stream = ConfigHelper.getResourceAsStream( resourceName ); calls

      stream = classLoader.getResourceAsStream( stripped );

The classloader returnes is org.jboss.modules.ConcurrentClassLoader which does this:

    public final URL getResource(final String name) {

        for (String s : Module.systemPaths) {

            if (name.startsWith(s)) {

                // Whatever loads jboss-modules.jar should have it's classes accessible.

                // This could even be the bootclasspath, in which case CL is null, and we prefer the system CL

                return definingLoader != null ? definingLoader.getResource(name) : ClassLoader.getSystemResource(name);

            }

        }

        return findResource(name, false);

    }

stream is 'null' in the end.

Update:

Probably packaging error on my side. At least for the import_files problem this works when i put the files into the jar with the testclasses, not the ear containing the whole test setup (albeit the persistence.xml is in the META-INF folder of the ear). Looks like the module class loader of the jar is used during hibernate schema export.

[nickarls]

Hmmm. One would think that since jar-file is in the spec, it should "just work". Since the jar is in the war lib, it is obviously in the classpath. The jar doesn't need any persistence.xml itself, right? And I think the path is correct to (just the full jar name) since that is what the persistence.xml editor of JBT suggests.

[th.janssen]

We are using the jar-file element without any problems in 7.1.1 but our deployment structure is different. Maybe its a problem with the automatic dependency resolution?

We have an ear with multiple jar files containing entities. These jars are declared as modules in the application.xml and only one of these jar files contains the persistence.xml file in its META-INF and references the other jars. So the differences are jars as modules in ear and persistence.xml in META-INF of a jar.

[nickarls]

Trying to summon a Scott Marlow

Do you see anything obviously wrong or should I try with a JIRA + test case?

[smarlow]

Can you try enabling TRACE logging for org.jboss.as.jpa and see if the console logging output helps explain what is going on during deployment.

[smarlow]

Also, there is a unit test in https://github.com/jbossas/jboss-as/tree/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/jarfile that could be modified as needed to recreate the failures that you guys are seeing (if needed).

[nickarls]

Enabling the correct trace logging helped me find the issue. I used JBoss Tools for picking the jar-file entry and it resolved to <jar-file>framework.jar</jar-file>. However, during deployment WEB-INF/framework.jar was looked for. Changing the jar-file entry to lib/framework.jar solved the issue...