<p>Hi, Sahoo; I'd like to bring this topic back up if I may.</p>
<p>I'm still looking for the optimal solution (in terms of flexibility) for specifying my persistence units.</p>
<p>The way the application is composed is very granular. You can have, for example, an ejb-jar that knows how to work with Person entities, and one that knows how to work with Building entities. I want it to be the case that you COULD have an application with TWO persistence units--one for people, one for buildings--if you so choose. I also want to permit deploying it so that you may have only ONE persistence unit if you so choose.</p>
<p>Furthermore, the ejb-jars have no idea what application they're going to be part of.</p>
<p>SO:</p>
<p>If I put persistence.xml files in each ejb-jar file (one in person-ejb.jar and one in building-ejb.jar, for example), then what do I call the persistence units inside them? If I name them after the functionality (e.g. "persistence/PersonManagement", "persistence/BuildingManagement"), what happens when someone wants to build an application that uses one big honking database for both people and buildings?</p>
<p>So my thought was to just defer all of this to application assembly time. I made a separate jar and put the One True persistence.xml file in there. It would be understood that the application assembler would edit this persistence.xml file to define as many or as few persistence units as he wanted.</p>
<p>But if he does this--and if I take this deployment strategy path--then I want to take care in my EJBs not to specify a persistence unit name (since I don't know what it is).</p>
<p>So my current structure is:</p>
<ul>
<li>ear has persistenceUnit.jar in its lib dir. That jar has META-INF/persistence.xml that looks like this:
[code]<persistence ...>
<persistence-unit name="SomeNameHere">
...
</persistence-unit>
</persistence>
[/code]
That is the only persistence.xml in the whole EAR anywhere.</li>
<li>All EJBs that require an EntityManager are annotated with just @PersistenceContext. No unit name specified, no deployment descriptors, no nothing. I understand from the EJB specification that if there is only one persistence unit in the ear (which there is) that I don't have to specify the unit name in any way.</li>
</ul>
<p>I run the verifier on this ear and everything passes.</p>
<p>Now it looks like an alternative strategy--and here's where I could use some help--is something like this:</p>
<ul>
<li>Have each ejb initialize its own EntityManager (either via annotations or lookup or whatever) with a specific reference to a persistence unit whose name <i>the ejb itself determines</i>. So perhaps the person management EJB decides that it will depend on a persistence unit named "persistence/PersonManagement".</li>
<li>Then make it a necessary step of application assembly that the Application Assembler add or edit the ejb-jar.xml files (which currently don't exist) and "retarget" these references at a common persistence unit (in accordance with section 16.11.2 of the EJB core specification) that is found inside the application itself.</li>
</ul>
<p>My only problem with THAT is that it seems really, really, really, really cumbersome. As I see it, it goes something like this:</p>
<ol>
<li>Unzip the .ear somewhere.</li>
<li>Start with the first EJB (let's say the person management EJB) jar. Unzip it too.</li>
<li>See if it has an ejb-jar.xml file. Let's say it does.</li>
<li>Edit its persistence-unit-ref information so that the ref refers to a persistence unit name the application assembler knows about (e.g. ../lib/someJarContainingPersistenceXml#TheOneTruePersistenceUnit).</li>
<li>Repeat times the number of EJBs.</li>
</ol>
<p>Am I missing something here? This seems more...decoupled, sure, but also really complicated. Is there an alternative?</p>
<p>Best,<br/>
Laird</p>
[Message sent by forum member 'ljnelson' (ljnelson)]
http://forums.java.net/jive/thread.jspa?messageID=264596