I do this all day long.
You have a Library project with the Entities AND the Remote Interfaces.
You have an EJB project with your Session Beans and a dependency on the Library.
You have a WAR project with a dependency on the Library.
Make sure no packages are shared across the 3 deployment units, I think things get wonky when you have the same package (even with different classes) deployed in libs and EJBs... (so don't have, say, pkg.ejb.interfaces with the Remote interfaces in the lib and the Locals in the EJB. Better to have pkg.ejb.interfaces.remote.* and pkg.ejb.interfaces.local.*)
In the EJB project, you configure the persistence.xml to load the entities from the Library.
In the end, the WAR simply has the Library jar bundled with it. To the WAR, they're generic POJO's and Interfaces.
The EJB actually leverages the Entity annotations etc and manages the JPA bits.
I've run in to Marshalling errors as well, these typically occur if the library has changed. I have not taken it to the point of see if it's simpy a serialization issue and need to set the versionid on the classes, I've just redeployed both the EJB and WAR.
But in theory there should be a way to stabilize the marshalling errors.
The turnaround is good like this, I like having the WARs separately deployed. But be careful as the Remote interfaces CAN be expensive. Easy to get sloppy with Local interfaces by moving too much data around, you'll pay for that when you got Remote, even in the same container. Also have to be cognizant about lazy loading and such as well. You can be sloppy about that with TopLink and local interfaces, but not with Remote interfaces.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=254079