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 ]