641 words

ObjectDB within a resource adapter module and Java EE Connector Architecture

#1
2016-11-19 11:19

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 ?

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
webel
webel's picture
Joined on 2011-05-27
User Post #124
#2
2016-11-20 12:43

Support of the Java EE Connector Architecture has never been implemented in ObjectDB.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #2,656
#3
2016-11-21 01:40

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:

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.

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
webel
webel's picture
Joined on 2011-05-27
User Post #125
#4
2016-11-21 07:44

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:

http://stackoverflow.com/questions/8784302/dynamic-persistencecontext-unitname-attribute-for-container-based-entitymanager

http://stackoverflow.com/questions/9957179/jpa-dynamic-persistence-unit-name

http://stackoverflow.com/questions/33790875/how-to-dynamically-modifying-unitname-in-persistencecontext

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.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #2,661
#5
2016-11-21 10:14

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:

.../SpecWeb1/build/web/WEB-INF/db/samename.odb
.../SpecWeb2/build/web/WEB-INF/db/samename.odb

(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:

.../spec1/objectdb/external/db/samename.odb
.../spec2/objectdb/external/db/samename.odb

 

 

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
webel
webel's picture
Joined on 2011-05-27
User Post #126
#6
2016-11-22 01:51

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.

 

--- Webel IT Australia, "The Elements of the Web", Specialists in model-based UML, SysML, Enterprise Java, XML, and Drupal CMS web engineering. Dr Darren Kelly, BSc, PhD, https://www.webel.com.au
webel
webel's picture
Joined on 2011-05-27
User Post #127

Post Reply

Please read carefully the posting instructions - before posting to the ObjectDB website.

  • You may have to disable pop up blocking in order to use the toolbar (e.g. in Chrome).
  • Use ctrl + right click to open the browser context menu in the editing area (e.g. for using a browser spell checker).
  • To insert formatted lines (e.g. Java code, stack trace) - select a style in the toolbar and then insert the text in the new created block.
  • Avoid overflow of published source code examples by breaking long lines.
  • You may mark in paragraph code words (e.g. class names) with the code style (can be applied by ctrl + D).
  • Long stack traces (> 50 lines) and complex source examples (> 100 lines) should be posted as attachments.
Attachments:
Maximum file size: 32 MB
Cancel