Has anybody managed to use ObjectDB in a resource adapter module in accordance with the Java EE Connector Architecture so that it may be packaged separately from (but used by components of) an EJB Module after the pattern of the classic EAR File structure as illustrated in the Java EE 7 tutorial in Figure 5-1 EAR File Structure ?
ObjectDB within a resource adapter module and Java EE Connector Architecture
Support of the Java EE Connector Architecture has never been implemented in ObjectDB.
If a separate resource adapter module can't be used, is there another @PersistenceContext-friendly strategy for separating at least the name of the final database file from an EJB module that leverages a persistence unit associated with it ?
Example: JPA-style: 2 separate end-project web apps leverage the same EJBs, which in turn leverage the persistence.xml, which is automatically used via:
@PersistenceContext private EntityManager em;
The 2 web apps end up using the same persistence.xml, and thus the same ObjectDB database file name.
Under http://www.objectdb.com/java/jpa/start/connection it is explained that:
'JPA requires the definition of a persistence unit in an XML file in order to be able to generate an EntityManagerFactory. But when using ObjectDB you can either define a standard persistence unit in an XML file or you can simply provide the file path of the ObjectDB database instead:'
EntityManagerFactory emf = Persistence.createEntityManagerFactory("$objectdb/db/points.odb");
But if you are not using an explicit EntityManagerFactory it is not clear to me how to "inject" easily specs for which per-end-project database file to use.
You can specify a persistence unit name (which can also be an ObjectDB database url) in the unitName parameter of @PersistenceContext, but this seems to form a static binding.
See the following discussions ragarding possible solutions:
Not particularly nice but should work if the number of databases is small.
Maybe we can extend the way that ObjectDB interprets urls as implicit persistence units, and support some syntax that replaces a logical path with a parameter (similar to $objectdb in the url) with a value from a system property. Check what can work for you and if you define a simple feature request we may be able to implement it.
Thanks for your detailed response and research links.
In the meantime, I noticed the following if I use the following module structure:
CoreEntity (can instead by included with CoreEJB module) CoreEJB (has the persistence.xml, CRUD ops and business logic ops) CoreWeb (common JSF managed bean classes that only speak to DB via EJBs) SpecWeb1 (1st specific web app project, uses shared CoreWeb, CoreEJB etc.) SpecWeb2 (2nd specific web app project, uses shared CoreWeb, CoreEJB etc.)
The database file (defined in the persistence.xml) by default at least gets written respectively to:
(for the case where deployed over .../build). The odb filename is the same in both case, but at least the path is clear. Note also that the user and password are also identical (shared) if defined in the persistence.xml in the CoreEJB module.
If SpecWeb1 and SpecWeb2 respectively use different @Singleton @Startup beans to set objectdb.home, I can likewise for WAR deployment in a final server at least ensure that the databases are at different paths:
Related, from IBM Knowledge Center: EJB 3.x module packaging overview:
Persistence units, including the persistence.xml file and the classes associated with it, can be packaged in the module for which they are required. They can also be packaged in the separate utility JAR file that is packaged in the EAR file with its dependent module.
When a separate utility JAR file is packaged, it is necessary for the module that desires it to use the persistence units to declare a dependency on the utility JAR file using the typical MANIFEST. MF Class-Path: declarations ...
(I am however not currently using full EAR packaging.)
The EntityManager producer strategies you linked to look like good candidates for my current modular project structure, where everything is ultimately combined into a WAR with various modules as JARs under web/WEB-INF/lib.