Hi Dennis, If you don't want to use your Java EE's JPA integration features, you might want to look at setting things up so that your content container is generally a "persistence container" in the parlance of the JPA spec.
This means that your container would be responsible for EntityManager lifecycle and potentially for transaction control. It also means that you'd interact with OpenJPA via the PersistenceProvider.createContainerEntityManagerFactory() API. In such a scenario, you (the container) would be responsible for providing a PersistenceUnitInfo (you might want to take advantage of OpenJPA's existing XML-processing support to help out with this). The benefit of doing this is that it would provide the JPA consumers (your internal team and extenders of your product) with runtime and deployment semantics similar to what the JPA spec already does, possibly with your own tweaks here and there to support additional features. -Patrick On 5/14/07, Dennis Thrysøe <[EMAIL PROTECTED]> wrote:
Hello, I'm planning on embedding OpenJPA in a server (which is running in a J2EE environment). OpenJPA will run entirely within this server, and together with added functionality implement a "content container" in which entities can be depolyed, just as servlets can in a servlet container. So, I was wondering if anybody here could help me get a little wiser on OpenJPA. Does OpenJPA: - Allow arbitrary instatiation and destruction, without requiring anything directly from the J2EE framework? - Allow dynamic deployment of Entities when they are loaded, or at deployment time. - Allow "third parties" (not the entity definitions) to define/override things such as identity definition, field types (convert when reading/writing etc.? Any thoughts welcome. -dennis --------------------------------------------------------------------------- The information in this email is confidential and may be legally protected.
-- Patrick Linskey 202 669 5907
