DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Key: NUCCORE-922
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Andy Jefferson
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
DataNucleus Core

JPA : Enhance classes to implement org.datanucleus.enhancer.Persistable to avoid dependency on JDO

Created: 30/Oct/07 09:03 AM   Updated: 24/Apr/14 10:48 AM   Resolved: 21/Apr/14 09:59 AM
Component/s: Enhancer
Affects Version/s: None
Fix Version/s: 4.0.0.m3

 Description  « Hide
Currently DataNucleus enhances all classes to implement javax.jdo.spi.PersistenceCapable. This means that DataNucleus used as a JPA implementation has a dependency on JDO (jdo-api.jar). We could avoid this by enhancing to an internal contract. The downside is that the user would have to have DataNucleus wherever they are using enhanced classes (rather than jdo-api.jar), so benefit-wise its positive for JPA, but little benefit for JDO.

"JDO" is basically the API+metadata as well as the enhancement contract. If we change the enhancement contract to use our own Persistable class (with method getExecutionContext instead of getPersistenceManager) as well as a StateInterrogation object then users should see no visible difference except for
1. Built-in single field id classes will be internal variants (but we could detect any explicit "javax.jdo.identity.*" metadata specification and change to the internal classes).
2. Maybe some JDOHelper method would not work?

Once this is done then the JDOStateManager could become
StateManagerImpl implements ObjectProvider<Persistable>
and have no JDO references (and core would lose its jdo-api dependency)

Sort Order: Ascending order - Click to sort in descending order
Matthew T. Adams added a comment - 23/Feb/13 07:07 AM
This makes sense mainly for runtime enhancement. If you're enhancing with DataNucleus at runtime, then you **know** you're going to need DataNucleus stuff in the classpath to do it.

Andy Jefferson added a comment - 21/Apr/14 09:59 AM
GitHub master now uses an internal bytecode enhancement contract using org.datanucleus.enhancer.Persistable. Means that a user will require datanucleus-core in their CLASSPATH when handling enhanced classes; not seen as a major problem since they can use enhanced or unenhanced classes in different parts of their application with little effort, and its better than insisting on jdo-api.jar to be present (since that will never be part of JavaSE or JavaEE anyway).