[hibernate-dev] Unable to dispatch Entities in different jars

Bouiaw bouiaw at gmail.com
Fri Feb 19 09:23:21 EST 2010

I agree with you, merging persistence.xml is ugly.
But more than a specific IDE issue, I think this is more a general
"dynamically discover Entites in != classloaders" related issue.

I have made some prototypes and my conclusion is that JPA is not build
for my use case, even if it is a real need as soon as you start to
build modular application.

I finally succeeded using Spring scanning approach. The idea is to
build a custom PersistenceUnitManager, where I specify entities
packages to scan in various classloaders (like you can specify
packages to scan in order to discover Spring or J2EE6 beans), scan
them and then use pui.addManagedClassName() in order to add them to
the pui.

You can see my implementation with Spring 3.0 here :

In my case, the packagePatternToScan property is set to

What do you think of this approach ?

On Fri, Feb 5, 2010 at 5:52 PM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Guys,
> The approach consisting of merging persistence.xml files is super broken. Period. It's a hack that happens to work for some version(s) of Hibernate but surely fails on other providers and is totally against the spirit and the word of the spec.
> The only decent approach I can think of is for the IDE to:
>  - implement PersistentUnitInfo and use the initialization process a container uses. After all an IDE is a container. For some reason, you don't like this one.
>  - the IDE does the scanning and use the Hibernate specific configuration APIs in Ejb3Configuration (like addClass)
>  - write your own scanning approach, it's all abstracted behind org.hibernate.ejb.packaging.Scanning. There is no way to pass a custom Scanning implementation but I am open to suggestions on the way to do it.
> Emmanuel
> On 5 févr. 2010, at 14:38, Max Rydahl Andersen wrote:
>> This discussion is super relevant for multi module project development in IDE's too.
>> I've followed up - I hope emmanuel do too since this one actually is one of my
>> biggest issues I have when it comes to "autoscanning".
>> /max
>> ----- "Bouiaw" <bouiaw at gmail.com> wrote:
>>> Thanks for your answer.
>>> I made some tests but I think there is no way to acheive this my
>>> (common) need without tweaking with merging in one PU.
>>> I don't want to SPAM the dev list so I created a thread on the
>>> Hibernate forum with my feedback :
>>> https://forum.hibernate.org/viewtopic.php?f=1&t=1002467
>>> On Thu, Feb 4, 2010 at 9:06 AM, Emmanuel Bernard
>>> <emmanuel at hibernate.org> wrote:
>>>> Splitting entities amongst several JARs is definitely supported by
>>> JPA 2, you need to use the <jar-file> element in persistence.xml (or
>>> to a lesser extend <class>).
>>>> Merging several persistence.xml and considering them one is not a
>>> concept that makes sense in the JPA 2 spec. Conceptually that means a
>>> lot of metadata duplication that can and will conflict.
>>>> The exception you see comes from the fact that your "merging" does
>>> not "unduplicate" jar file urls and it's associated root url.
>>>> Emmanuel
>>>> On 3 févr. 2010, at 17:43, Bouiaw wrote:
>>>>> Hi,
>>>>> I would like to warn you about a blocking (from my point of view)
>>>>> issue in Hibernate 3.5 (JIRA issue :
>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4864).
>>>>> Dispatching entities is not supported out of the box by
>>> Hibernate/JPA,
>>>>> but with a small tweak commonly used
>>> (http://ancientprogramming.blogspot.com/2007/05/multiple-persistencexml-files-and.html)
>>>>> it is possible to acheive this.
>>>>> This worked with previous version of Hibernate, but not anymore in
>>>>> Hibernate 3.5 betas.
>>>>> Even if this is not specified in JPA, this is mandatory for a lot
>>> of
>>>>> developer to do modular applications (each module (JAR) provide
>>> its
>>>>> own DAO, business and model layer).
>>>>> I hope you will be able to fix HHH-4864, because this is a
>>> blocking
>>>>> point for a lot of developers.
>>>>> Thanks in advance for your feedback,
>>>>> Bouiaw
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> --
>> /max

More information about the hibernate-dev mailing list