How to configure Hibernate console with entities in many pro

[chawax]

Hi,

I have JPA entities that depend on entities defined in another project. For example I have a t4-core-commons project that depends on a t4-core-utils project (for example @ManyToOne annotation).

I try to configure hibernate console for these projects. No problem to configure it on t4-core-utils project. But I can't find how to do with t4-core-commons : it fails because it can't find entities defined in t4-core-utils project.

I added t4-core-utils project to the classpath but it can't find them. Also tried to add t4-core-utils project as first entry in the classpath list : entities from t4-core-utils are found, but not one of t4-core-commons.

I encountered the same kind of problems with unit tests and solved it thanks to the <jar-file> property in persistence.xml. Is there something equivalent with Hibernate Console ?

Thanks in advance,

Olivier

[maxandersen]

hibernate console should just pick them up for you by being in the classpath of the project - if not its a bug.

<jar-file> should also work, but you would need a jar file to be present ;)

[chawax]

Thanks Max.

My other projects are mavenized, so I have the needed jar file :) But where should I set ejb-jar ? Do I have to do it in a persistence.xml file ? If so, does Hibernate look for persistence.xml file in classpath (this would be a problem for me since I have different persistence.xml files my both projects because of jar-file property) ? Or is there a way to tell Hibernate console to use one specific persistence.xml file ?

Anyway I can make it work by adding to the classpath a jar that shades both t4-core-commons.jar and t4-core-utils.jar (I had to build this one to make hbm2ddl work). But since Hibernate console is to be used when writing HQL, I don't find very convenient to have to build jars before entities are not completely written.

[maxandersen]

Console just uses hibernate to load the classes/persistence.xml just like hibernate annotations/entitymanager would do.

You can tell hibernate console which persistence unit to pick (i.e. the name of it, not the location)

its weird that it works if you add the jar to the classpath - I wonder why the pure classes classpath does not work...

[chawax]

Yes, I hardly understand why it doesn't work.

To be more precise, my t4-core-commons project contains this persistence.xml file :

<?xml version="1.0" encoding="UTF-8"?>
<persistence
 xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
 version="1.0">
 <persistence-unit name="t4Seam">
 <provider>org.hibernate.ejb.HibernatePersistence</provider>
 <jta-data-source>java:/jdbc/t4Seam</jta-data-source>
 <jar-file>../test-classes/lib/t4-core-utils-core.jar</jar-file>
 <properties>
 <property name="hibernate.hbm2ddl.auto" value="update"/>
 <property name="hibernate.show_sql" value="false"/>
 </properties>
 </persistence-unit>
</persistence>

And t4-core-utils.jar contains the following persistence.xml file :

<?xml version="1.0" encoding="UTF-8"?>
<persistence
 xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
 version="1.0">
 <persistence-unit name="t4Seam">
 <provider>org.hibernate.ejb.HibernatePersistence</provider>
 <jta-data-source>java:/jdbc/t4Seam</jta-data-source>
 <properties>
 <property name="hibernate.hbm2ddl.auto" value="update"/>
 <property name="hibernate.show_sql" value="false"/>
 </properties>
 </persistence-unit>
</persistence>

I have some doubts on Hibernate behaviour when it finds two persistence.xml files with the same persistence unit in the classpath. It looks like it takes into account only the first one it finds in classpath. If t4-core-commons is first in the classpath, it crashes because it can't find entities defined in t4-core-utils. If t4-core-utils is first in the classpath, it loads only entities defined in t4-core-utils (entities there don't depend on t4-core-commons ones) and not the ones defined in t4-core-commons. The only solution I found to make it work is to build a jar that bundles entities of both t4-core-commons and t4-core-utils, but as I said it's not very convenient. Do you have more details about the way Hibernate behaves if it finds a persistenc unit twice ?

[maxandersen]

well, autoscanning don't work across the persistence unit the persistence.xml is located in.

I'll ping emanuel to let him in explain if there are any workarounds.

[chawax]

Thanks for your response Max. I have a workaround for the moment as I said, not very convenient, but at least it exists ! It would be great anyway if Emmanuel has a better workaround.

[epbernard]

Can you try to not give them the same name. If these are supposed to be the same PU, why several files. If they are supposed to be different PU, why the same name :)

Anyway I don't think it's related to your problem.
One way to work around it is to manually list the classes in persistence.xml
org.jboss.example.model.Account

That way the auto discovery mechanism is bypassed.

Generally speaking if entities are not stored in the same root directory as META-INF/persistence.xml, the discovery mechanism will miss them.

[chawax]

Well, I made several files for development organization reasons : many development teams will work on the project and they will rely on common entities for standard needs. At the end, all these projects are merged into one jar (t4-core-all) which will contain all entities and one unique persistence.xml (and so with one unique persistence unit). Anyway, I will try to manually list classes in persistence.xml. Will it work too if I have many persistence.xml files in the classpath ?

[maxandersen]

chawax - only one persistence.xml will be used for one persistence unit; so that persistence.xml would need to be in the root of the entities you want scanned + list the classes that is "outside"