Hi, I strongly suggest using Features, in favor of copying your dependencies to the deploy directory. Second, if you install the desired spring feature before the spring-dm one, you won't run into your scenario where you end up with the wrong spring-version.
I don't think it's really necessary to switch to OpenJPA (though it might help ;)) If you need more help just cry-out :) Regards, Achim 2014/1/27 Daniel McGreal <[email protected]> > Hi, > > I’m investigating moving from Virgo to Karaf. My application uses Spring > Data, initially with JPA using EclipseLink. > > My strategy so far has resulted in: > Caused by: java.lang.IllegalArgumentException: class > org.eclipse.persistence.jpa.osgi.PersistenceProvider is not assignable to > interface javax.persistence.spi.PersistenceProvider > at org.springframework.util.Assert.isAssignable(Assert.java:368) > at org.springframework.util.Assert.isAssignable(Assert.java:351) > at > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.setPersistenceProviderClass(AbstractEntityManagerFactoryBean.java:128) > at > com.redbite.redbox.persistence.repository.jpa.configuration.JpaPersistenceConfiguration.entityManagerFactory(JpaPersistenceConfiguration.java:42) > at > com.redbite.redbox.persistence.repository.jpa.configuration.JpaPersistenceConfiguration$$EnhancerByCGLIB$$3c404459.CGLIB$entityManagerFactory$1(<generated>) > at > com.redbite.redbox.persistence.repository.jpa.configuration.JpaPersistenceConfiguration$$EnhancerByCGLIB$$3c404459$$FastClassByCGLIB$$b6dd4002.invoke(<generated>) > at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:215) > at > org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:285) > at > com.redbite.redbox.persistence.repository.jpa.configuration.JpaPersistenceConfiguration$$EnhancerByCGLIB$$3c404459.entityManagerFactory(<generated>) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:160) > ... 17 more > > It looks like the class of the spi interface is not the same class that > the EclipseLink class has extended, possibly due to multiple versions of > bundles? > > I wonder if my strategy can be improved: > > > 1. I use Maven copy-dependencies to populate Karaf's deploy directory, > this includes Spring 3.1.4.RELEASE bundles (I haven’t installed them using > features) and EclipseLink, Spring Data (& JPA) and their dependencies, e.g. > CGLib & AopAlliance bundles. > 2. I install spring-dm manually (if I installed it using Karaf’s > features it starts loading things from a Spring 3.*2*.4.RELEASE > context somehow), e.g. installing each featured bundle and setting its > start-level to 30 manually. > 3. I deploy my spring bundle which configures a DataSource > and LocalContainerEntityManagerFactoryBean as beans using JavaConfig. > > > I don’t think I’m doing this the “Karaf Way” and wonder how it can be > improved? I’m not tied to EclipseLink, and could happily use e.g. OpenJPA. > > Thanks for any help you can offer, > Dan. > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
