How to layout Java EE projects using common JPA entities?

I have two eclipse J开发者_如何学Goava EE 6 projects packaged in a WAR-file using maven 3. Now they should share JPA entities in a 3rd project among them, since they both use the same database.

When doing the research for my question, I found some hints mentioning for example a reference in a persistence.xml to a common jar, but I wasn't successful to make it work. So specifically asked:

1) Does the project, containing the common entities, has a persistence.xml file? If so, how does it differ from the one in the other projects?

2) How exactly are the commonly used entities referenced in the two projects? Do I use the tag in their persistence.xml for reference? And if so, would "lib/MyCommon.jar" be the right way to use, if MyCommin.jar is located in WEB-INF/lib?

3) Does it make any difference if the application is deployed as a WAR or an exploded archive in JBoss 6?

4) When deployed within eclipse via addition to server runtime and publish, is there anything different from deploying outside eclipse?

5) Is the described way putting common entities in a separate project, creating a JAR and use that JAR in the other project a sensible way to handle the problem of sharing common entity classes or is there a better way?

1) Does the project, containing the common entities, has a persistence.xml file? If so, how does it differ from the one in the other projects?

Yes. The main difference is that the persistence.xml in the model project should define all entities and that the persistence.xml in the web projects should just reference the model project JAR file. Otherwise you keep duplicating entites in persistence.xml files.

Another possible difference is that the one in model project should use a resource local transaction type so that unit testing from within the project (e.g. using a main() method) is done very easily. The ones in web projects should of course use a datasource by e.g. JTA.

2) How exactly are the commonly used entities referenced in the two projects? Do I use the <jar-file> tag in their persistence.xml for reference? And if so, would "lib/MyCommon.jar" be the right way to use, if MyCommin.jar is located in WEB-INF/lib?

Yes and No. The <jar-file> is the right way, but you have a typo in the filename and the folder should be omitted. The lib folder is usually only used when you've an EAR and the JAR is included in EAR's lib folder.

<jar-file>MyCommon.jar</jar-file>

3) Does it make any difference if the application is deployed as a WAR or an exploded archive in JBoss 6?

No. Properly designed Java API's don't rely on the local disk file system, but just on the classpath. It makes for the classpath no difference if the WAR is expanded or not.

4) When deployed within eclipse via addition to server runtime and publish, is there anything different from deploying outside eclipse?

Technically, yes. Functionally, no.

5) Is the described way putting common entities in a separate project, creating a JAR and use that JAR in the other project a sensible way to handle the problem of sharing common entity classes or is there a better way?

It makes definitely sense. You don't want to repeat yourself.

From my experience, each jar must have a persistence xml, and that means that each EntityManager will be bound to one persistence xml. This means that in order to have transactions that involve entities from different jars, you'll need to use a JTA provider. One option to avoid what I mentioned above, is to have some Ant or Maven task to assemble classes from different jars into a new jar which contains the final persistence xml.

Having said that, in the projects where I used a shared project to put my entities, I had to end up putting all my entities (for the reason above).

I now think that the best way to do this, is to break the system into vertical modules, where each module manages it's own entities and can reference entities in other modules just by id. This is the best way I've found to build SOA applications and normal apps too. The reason to do this, is that it reduces the coupling drastically between the entities and modules too.

A few questions to ask yourself

• Do you really want 2 different applications to update the same database tables?
• What are you going to do if you need to update one application but the other one should remain the same?
• Do the entities expose more information that the application really needs?