Hi all,

Hibernate version: 3.05
JBoss version: 4.02
Name and version of the database you are using: Oracle 8.1.7
Java version: 1.5.0_05

We are currently trying to migrate our EJB2.0 entity beans architecture (using MVCSoft mapping tool) to hibernate and jboss 4. Now we are facing some new challanges:

Now we have several EARs that are deployed in JBoss. One EAR is our "core" application and all other EAR have a dependency to it. Each EAR contains a .har file that is a hibernate service. We defined this structure to get all EARs (except the "core" one) fully hot-deployable and keeping the rest deployed to enhanced our uptime.

In the "core" EAR, we have one HAR that deploy several entites. Other EARs have also several entites.

Our problem is that we would like to have relationships between "core" EAR entites and orther EARs entites as well as just one Hibernate cache and as well to keep applications hot-deployable...

If we define simply the relationship as if all entites would be in the same EAR, the hibernate service throw an exception : org.hibernate.MappingException: An association from the table SH_CUSTOMER refers to an unmapped class: ch.clx.hibernateshop.model.MobileUser

Can you please say us, if this possible is, what would be the best solution to keep the modularity with several EARs and in the same time permit to map relationships between EARs?

Thanks in advance for your response!

this is not possible using hars. a har explicitly defines a single SessionFactory; the purpose of the har archive being to "scope" the resources that should be used to construct said SessionFactory (the idea is very similiar to what was adopted for ejb3 persistence units).

starting in jboss-as 4.0.3, however, the hibernate intg added the capability to bootstrap itself implicitly from the "deployment classpath". You might be able to leverage that to somewhat acheive what you are looking for. The problem there, however, would in fact be the hot-deployability. Re-deploying one of the "non-core" ears would not force redeployment of the core ear (which would be needed to rebuild its SessionFactory).

i have been thinking about the potential for a notion of allowing "satellite" deployments for a har. Basically it would use a different mbean which just added its contents to a configured org.jboss.hibernate.jmx.Hibernate mbean. but the trouble there is still even hot-redeployment (i.e. what should happen on "start" or "stop" of one of the satellites?

personally, i'd simply re-think your deployment scheme. in what you describe it really sounds like have multiple deployments all dependent upon a single "persistence unit". so i'd setup my deployments that way. have a stand-alone har dropped into "deploy/" which encapsulates all the domain model along with the Hibernate mbean definition; then define dependencies between the individual ears to this deployment. in 4.0.3, you can even make this a sar deployment using the "scanning" stuff I mentioned before. this way you can still hot-redeploy one of the non-core ears without effecting the other ears. if a change is made to the domain model, it seems reasonable that the ears should get redeployed anyway.