This could realistically be supported by having parallel packages inside the bundle with implementations for each version of the spec. The code can detect which version is available at runtime by trying to load the relevant types, and then can load the appropriate implementation.
Regards, Tim On 31 Jul 2014, at 13:57, Mark Nuttall <[email protected]> wrote: > Hello, > I've run into a problem with > https://issues.apache.org/jira/browse/ARIES-1047, under which Jean-Baptiste > moved the Aries JPA code up to JPA 2.1. The Aries JPA code no longer works > on a JPA 2.0 implementation. > > For example, the javax.persistence.StoredProcedureQuery class is new in > 2.1. javax.persistence.EntityManager has gained a number of new methods > such as createStoredProcedureQuery(). > org.apache.aries.jpa.container.impl.EntityManagerWrapper implements > EntityManager, so that now running Aries JPA with a 2.0 JPA implementation > gives runtime errors such as java.lang.ClassNotFoundException: > javax.persistence.StoredProcedureQuery cannot be found by > org.apache.aries.jpa.container.context. > > This is a serious problem for use at IBM since we have the JPA 2.0 code in > the field in commercial products which we need to be able to service for > many years to come. > > In short, I/we need Apache Aries JPA to continue to offer JPA 2.0 support, > as well as JPA 2.1. I think this will need a fork in the jpa module code, > but if anyone has any better suggestions, do please let me know. > > Regards, > Mark
