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
Operations

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)

Andy Jefferson made changes - 15/Jul/08 08:22 AM
Field Original Value New Value
Project JPOX Enhancer [ 10001 ] DataNucleus Enhancer [ 10165 ]
Key ENHANCER-101 NUCENHANCER-12
Component/s Enhancer Interface [ 10080 ]
Fix Version/s 1.2.3 [ 10263 ]
Andy Jefferson made changes - 06/Jun/09 10:30 AM
Component/s ASM Enhancer [ 10162 ]
Andy Jefferson made changes - 14/Nov/10 07:23 PM
Fix Version/s 3.0.0.release [ 11076 ]
Andy Jefferson made changes - 11/Mar/11 05:19 PM
Summary JPA : Enhance classes to implement org.jpox.jpa.Persistable to avoid dependency on JDO JPA : Enhance classes to implement org.datanucleus.api.jpa.Persistable to avoid dependency on JDO
Fix Version/s 3.0.0.release [ 11076 ]
Description Currently JPOX enhances all classes to implement javax.jdo.spi.PersistenceCapable. This means that JPOX used as a JPA implementation has a dependency on JDO (jdo2.jar). We should avoid this by enhancing for JPA 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 specifically for JPA. The downside is that the user would have to have DataNucleus wherever they are using enhanced classes (rather than just jdo-api.jar)
Andy Jefferson made changes - 05/Oct/12 05:06 PM
Project DataNucleus Enhancer (ARCHIVED) [ 10165 ] DataNucleus Core [ 10143 ]
Key NUCENHANCER-12 NUCCORE-922
Component/s Enhancer [ 10350 ]
Component/s ASM Enhancer [ 10162 ]
Andy Jefferson made changes - 18/Feb/13 03:09 PM
Summary JPA : Enhance classes to implement org.datanucleus.api.jpa.Persistable to avoid dependency on JDO JPA : Enhance classes to implement org.datanucleus.enhancer.spi.Persistable to avoid dependency on JDO
Description 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 specifically for JPA. The downside is that the user would have to have DataNucleus wherever they are using enhanced classes (rather than just jdo-api.jar) 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 specifically for JPA. The downside is that the user would have to have DataNucleus wherever they are using enhanced classes (rather than just jdo-api.jar), so benefit-wise its small.

All javax.jdo class usage is now restricted into very specific parts of org.datanucleus.enhancer (and NucleusContext) now so should be a (relatively!) straightforward job
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 made changes - 19/Apr/14 06:06 PM
Summary JPA : Enhance classes to implement org.datanucleus.enhancer.spi.Persistable to avoid dependency on JDO JPA : Enhance classes to implement org.datanucleus.enhancer.Persistable to avoid dependency on JDO
Description 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 specifically for JPA. The downside is that the user would have to have DataNucleus wherever they are using enhanced classes (rather than just jdo-api.jar), so benefit-wise its small.

All javax.jdo class usage is now restricted into very specific parts of org.datanucleus.enhancer (and NucleusContext) now so should be a (relatively!) straightforward job
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 specifically for JPA. The downside is that the user would have to have DataNucleus wherever they are using enhanced classes (rather than just jdo-api.jar), so benefit-wise its small.

"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)
Andy Jefferson made changes - 19/Apr/14 06:11 PM
Description 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 specifically for JPA. The downside is that the user would have to have DataNucleus wherever they are using enhanced classes (rather than just jdo-api.jar), so benefit-wise its small.

"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)
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)
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).

Andy Jefferson made changes - 21/Apr/14 09:59 AM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 4.0.0.m3 [ 12152 ]
Resolution Fixed [ 1 ]
Andy Jefferson made changes - 24/Apr/14 10:48 AM
Status Resolved [ 5 ] Closed [ 6 ]