Hi Tim, Thank you for your suggestion. Here's the problem: EntityManagerWrapper implements javax.persistence.EntityManager. In order to compile against JPA 2.1, EntityManagerWrapper must implement methods such as createStoredProcedureQuery() - this method returns an object of class javax.persistence.StoredProcedureQuery : this class _does not exist_ in JPA 2.0.
I cannot see how to write an EntityManagerWrapper that compiles against JPA 2.1 but that can be loaded when wired to JPA 2.0. What am I missing? Regards, Mark On 31 July 2014 14:02, Timothy Ward <[email protected]> wrote: > 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 > >
