Hi Mitesh, thanks for the reply.
To answer your question, the common entities are packaged and deployed as a jar file in the application ear and not pre-deployed as an application library or part of any jvm classpath during startup.
Based on the link you provided, I should be safe unless there is something about application class loader that I am not seeing. I should be able to verify the isolation by trying to find a class that's only packaged in the other application.
This is probably a silly question but are there any issues with jvm singletons that have been loaded by different class loaders. I'm curious if toplink is storing the derived entity mapping information in singletons without taking the persistence unit into consideration. In this case, the second persistence unit would replace the first persistence unit mapping information. The only problem with this observation is that the resulting mapping would be identical.
I would specify the same persistence unit for both apps but Toplink complains about this and does not attempt to verify overlapping entities are the same and merge new entities into the persistence unit. I've seen that someone came up with a hack for Hibernate to do a persistence unit merge but this was only for one app containing multiple persistence.xml files with the same persistence unit and not for multiple apps which is my situation.
Any other ideas / suggestions on how I can get around this problem?
In the mean time, I'll verify the class loader isolation is working as it should be.
Thanks
[Message sent by forum member 'redmondcs' (redmondcs)]
http://forums.java.net/jive/thread.jspa?messageID=285091