I changed to JTA and it seems better. Any idea when Karaf 4.2.1 will be out?
Best regards, Alex soto > On May 21, 2018, at 2:34 PM, Jean-Baptiste Onofré <[email protected]> wrote: > > Hi Tim, > > as said in my previous mail, SCR 2.1.0 is already ready on a branch and it > will be included in Karaf 4.2.1. > > Regards > JB > > On 21/05/2018 20:32, Tim Ward wrote: >> The JpaTemplate is not very sophisticated, and I was considering deprecating >> it now Transaction Control is available. >> The reason that you only have support for Required transactions is because >> the backing implementation is using Resource Local. This is a simple beast, >> incapable of managing multiple EntityManagers (and therefore suspending >> transactions). It also doesn’t do any decoration of the EntityManager, so >> supports can’t be handled because you have no way to know if you should >> close/flush or not. >> The XA version is more sophisticated, in that it can start or suspend >> transactions, but it would then require you to use a valid XA enlisting >> DataSource (which I’m assuming is still an unsolved problem for you). It >> therefore is unlikely to help you. >> I’m somewhat surprised that nobody from the Karaf side has come up with a >> way to use Felix SCR 2.1.0 in Karaf. It really shouldn’t be a big job to >> upgrade a single bundle in the runtime. >> Tim >> Sent from my iPhone >> On 21 May 2018, at 19:08, Alex Soto <[email protected] >> <mailto:[email protected]><mailto:[email protected] >> <mailto:[email protected]>>> wrote: >>> I ended up using Aries JPA 2.7.0 with the JpaTemplate approach. >>> I can’t spend more time on this. >>> >>> I suppose the next Karaf release will support OSGi 7.0, then I can try >>> again. >>> >>> >>> Now with Aries JpaTemplate, transactions are correctly rolled back on >>> exception, but I can’t use the /TransactionType.Supports/ option as it >>> throws exception: >>> >>> java.lang.IllegalStateException: Only transation propagation type REQUIRED >>> is supported. >>> >>> Any idea why? >>> >>> Best regards, >>> Alex soto >>> >>> >>> >>> >>>> On May 19, 2018, at 2:42 AM, Tim Ward <[email protected] >>>> <mailto:[email protected]><mailto:[email protected] >>>> <mailto:[email protected]>>> wrote: >>>> >>>> Hi Alex, >>>> >>>> Another simple option would be for you to not depend on the enRoute >>>> osgi.api pom, but just the things you want/need from the compendium >>>> individually so you can force the use of DS 1.3. >>>> >>>> At the very least you would need these jars. I’m not sure what (if >>>> anything) else you are using in this bundle. >>>> >>>> https://mvnrepository.com/artifact/org.osgi/org.osgi.service.component.annotations >>>> >>>> <https://mvnrepository.com/artifact/org.osgi/org.osgi.service.component.annotations> >>>> >>>> https://mvnrepository.com/artifact/org.osgi/org.osgi.service.transaction.control >>>> >>>> <https://mvnrepository.com/artifact/org.osgi/org.osgi.service.transaction.control> >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>> On 19 May 2018, at 07:58, Jean-Baptiste Onofré <[email protected] >>>> <mailto:[email protected]><mailto:[email protected] >>>> <mailto:[email protected]>>> wrote: >>>> >>>>> Hi Alex, >>>>> >>>>> I don't think it's a good idea to update only SCR without updating other >>>>> part of Karaf (ClassNotFoundException seems to come from a compendium >>>>> package). >>>>> >>>>> I strongly recommend to focus on the current 4.2.0 distribution and >>>>> clearly list the issue to me: I will add a sample (eventually identifying >>>>> the issue). >>>>> >>>>> Please, can you give me an access to your project in order to clearly >>>>> understand the issue (I'm a bit lost in the thread). >>>>> >>>>> NB: for pure BND/EnRoute question, it's better to ask on the bnd mailing >>>>> list IMHO. Thanks ! >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> >>>>> On 18/05/2018 20:07, Alex Soto wrote: >>>>>> Tried adding Felix SCR 2.1.0, but it looks like it is not as simple: >>>>>> org.osgi.framework.ServiceException: Service factory exception: >>>>>> org/osgi/service/cm/ManagedService >>>>>> at >>>>>> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350) >>>>>> ~[?:?] >>>>>> at org.apache.felix.framework.Felix.getService(Felix.java:3737) ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.metatype.internal.ManagedServiceTracker.addingService(ManagedServiceTracker.java:52) >>>>>> ~[?:?] >>>>>> at >>>>>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) >>>>>> ~[?:?] >>>>>> at >>>>>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) >>>>>> ~[?:?] >>>>>> at >>>>>> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) >>>>>> ~[?:?] >>>>>> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) >>>>>> ~[?:?] >>>>>> at >>>>>> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) >>>>>> ~[?:?] >>>>>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) >>>>>> ~[?:?] >>>>>> at org.apache.felix.framework.Felix.registerService(Felix.java:3587) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:120) >>>>>> ~[?:?] >>>>>> at org.apache.felix.scr.impl.Activator.start(Activator.java:100) ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697) >>>>>> ~[?:?] >>>>>> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) >>>>>> ~[?:?] >>>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:2146) ~[?:?] >>>>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) >>>>>> ~[?:?] >>>>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:161) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1116) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:996) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964) >>>>>> ~[?:?] >>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >>>>>> ~[?:?] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >>>>>> ~[?:?] >>>>>> at java.lang.Thread.run(Thread.java:748) [?:?] >>>>>> Caused by: java.lang.NoClassDefFoundError: >>>>>> org/osgi/service/cm/ManagedService >>>>>> at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?] >>>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) >>>>>> ~[?:?] >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?] >>>>>> at >>>>>> org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) >>>>>> ~[?:?] >>>>>> ... 33 more >>>>>> Caused by: java.lang.ClassNotFoundException: >>>>>> org.osgi.service.cm.ManagedService not found by org.apache.felix.scr [67] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) >>>>>> ~[?:?] >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?] >>>>>> at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?] >>>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) >>>>>> ~[?:?] >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?] >>>>>> at >>>>>> org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47) >>>>>> ~[?:?] >>>>>> at >>>>>> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) >>>>>> ~[?:?] >>>>>> ... 33 more >>>>>> Best regards, >>>>>> Alex soto >>>>>>> On May 18, 2018, at 12:46 PM, Jean-Baptiste Onofré <[email protected] >>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>> wrote: >>>>>>> >>>>>>> 4.2.1-SNAPSHOT already updated to DS 1.4 (SCR 2.1.0) (ready on one of >>>>>>> my branch). >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On 18/05/2018 17:50, Alex Soto wrote: >>>>>>>> Great, I solved the Eclipse problem. Thanks. >>>>>>>> Yes, Karaf provides DS 1.3, but no DS 1.4 out off the box. >>>>>>>> Maybe this is available from Aries? >>>>>>>> Best regards, >>>>>>>> Alex soto >>>>>>>>> On May 18, 2018, at 11:18 AM, Tim Ward <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Answers inline: >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> On 18 May 2018, at 16:55, Alex Soto <[email protected] >>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>> >>>>>>>>>> Thank you Tim for the very detailed explanation. >>>>>>>>>> There are two problems I don’t know how to resolve: >>>>>>>>>> >>>>>>>>>> 1- BND generates this for my bundle: >>>>>>>>>> >>>>>>>>>> Require-Capability: >>>>>>>>>> osgi.extender;filter:="(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))” >>>>>>>>>> >>>>>>>>>> This is because I use the @Component and @Reference annotations. >>>>>>>>>> This is strange, since I should be using OSGi R7, so I am not sure >>>>>>>>>> why it is saying 1.3.0. Now when try to run in Karaf, even though I >>>>>>>>>> am installing/scr/feature, it fails with unresolved requirement. >>>>>>>>> >>>>>>>>> So in the absence of information to the contrary this requirement is >>>>>>>>> added based on your usage of Declarative Services features. If you >>>>>>>>> use DS 1.3 features then DS 1.3 will be required. >>>>>>>>> >>>>>>>>> Since R7 added the bundle requirement annotations the @Component >>>>>>>>> annotation has been annotated to require DS at the current spec >>>>>>>>> version (this gives a more consistent behaviour than bnd’s >>>>>>>>> heuristics). At a guess you are picking up a 1.3 requirement because >>>>>>>>> you have the 1.3 annotations ahead of the 1.4 annotations on your >>>>>>>>> classpath, but it could be triggered by other things too. On the >>>>>>>>> other hand this isn’t actually a problem as the requirement is still >>>>>>>>> satisfied by DS 1.4 and both versions will work for you at runtime. >>>>>>>>> >>>>>>>>> The Karaf scr feature really should be providing SCR 1.3 (which is >>>>>>>>> required by the spec to provide the extender capability. That has >>>>>>>>> been the current version of the spec for three years, and has been >>>>>>>>> provided by Felix for at least 6 releases. I’d be pretty shocked if >>>>>>>>> DS 1.3 wasn’t supported. You may need help from a more Karaf focussed >>>>>>>>> person to confirm this. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Since I could not find OSGi R7 in public Maven Repos, I followed >>>>>>>>>> EnRoute depending on: >>>>>>>>>> <dependency> >>>>>>>>>> <groupId>org.osgi.enroute</groupId> >>>>>>>>>> <artifactId>osgi-api</artifactId> >>>>>>>>>> <version>7.0.0-SNAPSHOT</version> >>>>>>>>>> <type>pom</type> >>>>>>>>>> <scope>provided</scope> >>>>>>>>>> </dependency> >>>>>>>>>> <dependency> >>>>>>>>>> <groupId>org.osgi.enroute</groupId> >>>>>>>>>> <artifactId>enterprise-api</artifactId> >>>>>>>>>> <version>7.0.0-SNAPSHOT</version> >>>>>>>>>> <type>pom</type> >>>>>>>>>> <scope>provided</scope> >>>>>>>>>> </dependency> >>>>>>>>> >>>>>>>>> There’s no problem with you using these. On the other hand the OSGi >>>>>>>>> API aggregations you are looking for are: >>>>>>>>> >>>>>>>>> https://mvnrepository.com/artifact/org.osgi/osgi.core >>>>>>>>> <https://mvnrepository.com/artifact/org.osgi/osgi.core> >>>>>>>>> >>>>>>>>> https://mvnrepository.com/artifact/org.osgi/osgi.cmpn >>>>>>>>> <https://mvnrepository.com/artifact/org.osgi/osgi.cmpn> >>>>>>>>> >>>>>>>>> You can also find the individual specs under the org.osgi group id if >>>>>>>>> you want to use a smaller hammer :) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2- This is minor, and I see it also in the EnRoute project. While >>>>>>>>>> the Maven build succeeds, Eclipse BND plugin shows 2 errors: >>>>>>>>>> >>>>>>>>>> The default package '.' is not permitted by the Import-Package >>>>>>>>>> syntax. This can be caused by compile errors in Eclipse >>>>>>>>>> because Eclipse creates valid class files regardless of compile >>>>>>>>>> errors. The following package(s) import from the default >>>>>>>>>> package [org.enquery.encryptedquery.responder.data.service.impl] >>>>>>>>>> >>>>>>>>>> (biz.aQute.bnd:bnd-maven-plugin:4.0.0:bnd-process:default:process-classes)pom.xml/encryptedquery-responder-dataline >>>>>>>>>> 0Maven Build Participant Problem >>>>>>>>>> >>>>>>>>>> The project was not built since its build path is incomplete. >>>>>>>>>> Cannot find the class file for javax.persistence.EntityManager. >>>>>>>>>> Fix the build path then try building this >>>>>>>>>> projectencryptedquery-responder-dataUnknownJava Problem >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> As the message suggests, this usually occurs when Eclipse has build >>>>>>>>> errors for the project. Specifically in this case you seem to be >>>>>>>>> building against a project which exposes the EntityManager interface >>>>>>>>> somehow, but you don’t have the JPA API in your compile dependencies >>>>>>>>> (normally these would come come in transitively from the project you >>>>>>>>> depend on). >>>>>>>>> >>>>>>>>> I hope this helps, >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Alex soto >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On May 18, 2018, at 5:23 AM, Tim Ward <[email protected] >>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Alex, >>>>>>>>>>> >>>>>>>>>>> The bundles you need are listed in the bndrun for the JPA version >>>>>>>>>>> of the enRoute application, but as I think you’re using OpenJPA >>>>>>>>>>> (rather than Hibernate) it may help to explain things in relation >>>>>>>>>>> to the Transaction Control JPA integration test for OpenJPA. I’m >>>>>>>>>>> sure that at least some of this will be stuff you already know, but >>>>>>>>>>> I’m trying to make sure I give a compete explanation. >>>>>>>>>>> >>>>>>>>>>> This method defines some extra properties to add to the persistence >>>>>>>>>>> unit. It references a couple of open bugs in OpenJPA which may or >>>>>>>>>>> may not affect you. It also adds schema generation as OpenJPA does >>>>>>>>>>> not support the standard properties from JPA 2.1 >>>>>>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L34 >>>>>>>>>>> >>>>>>>>>>> <https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L34> >>>>>>>>>>> >>>>>>>>>>> This method defines the OpenJPA bundles and their immediate >>>>>>>>>>> dependencies. >>>>>>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L48 >>>>>>>>>>> >>>>>>>>>>> <https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L48> >>>>>>>>>>> >>>>>>>>>>> You then need: >>>>>>>>>>> >>>>>>>>>>> • Aries JPA 2.7.0 - this provides the OSGi JPA Service 1.1 RI (1.1 >>>>>>>>>>> features are needed by the Aries Tx Control JPA resource provider >>>>>>>>>>> to support XA) >>>>>>>>>>> >>>>>>>>>>> • Aries Tx Control Service - either XA or local depending on >>>>>>>>>>> whether you need XA Transaction support. For example >>>>>>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L365 >>>>>>>>>>> >>>>>>>>>>> <https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L365> >>>>>>>>>>> >>>>>>>>>>> • Aries Tx Control JPA resource provider - either XA or local >>>>>>>>>>> depending on your needs. Note that you can’t use the XA provider >>>>>>>>>>> with the local service, but you can use the local provider with the >>>>>>>>>>> XA service (although this doesn’t make a lot of sense to do). For >>>>>>>>>>> example >>>>>>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L377 >>>>>>>>>>> >>>>>>>>>>> <https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L377> >>>>>>>>>>> >>>>>>>>>>> • A JDBC Service implementation supporting your database driver. H2 >>>>>>>>>>> supports this natively (which is why it is used in many examples) >>>>>>>>>>> but MariaDB does not. Therefore you will need to deploy PAX-JDBC’s >>>>>>>>>>> support. See >>>>>>>>>>> https://github.com/ops4j/org.ops4j.pax.jdbc/tree/master/pax-jdbc-mariadb >>>>>>>>>>> >>>>>>>>>>> <https://github.com/ops4j/org.ops4j.pax.jdbc/tree/master/pax-jdbc-mariadb> >>>>>>>>>>> >>>>>>>>>>> You then have the option of either programmatically assembling your >>>>>>>>>>> Resource Provider, or using configuration. Configuration is >>>>>>>>>>> generally easier and is what I normally recommend. At that point >>>>>>>>>>> you need to create a factory configuration for the relevant PID (it >>>>>>>>>>> depends on whether you use the local or XA resource provider, see >>>>>>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L175 >>>>>>>>>>> >>>>>>>>>>> <https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L175>) >>>>>>>>>>> >>>>>>>>>>> The necessary configuration properties are: >>>>>>>>>>> >>>>>>>>>>> • url - the JDBC URL for your database >>>>>>>>>>> • osgi.jdbc.driver.class - the database driver class name, in your >>>>>>>>>>> case org.mariadb.jdbc.Driver >>>>>>>>>>> • osgi.unit.name - the name of your persistence unit >>>>>>>>>>> >>>>>>>>>>> The result of this configuration will be a JPAEntityManagerProvider >>>>>>>>>>> service registered in the service registry (using your >>>>>>>>>>> EntityManagerFactoryBuilder and the MariaDB DataSourceFactory). You >>>>>>>>>>> can then Inject that service into your code and combine it with the >>>>>>>>>>> TransactionControl service to make a thread safe EntityManager that >>>>>>>>>>> you can use in all your requests (just like the enRoute example >>>>>>>>>>> does). >>>>>>>>>>> >>>>>>>>>>> I hope this helps, >>>>>>>>>>> >>>>>>>>>>> Tim >>>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>> On 17 May 2018, at 22:46, Alex Soto <[email protected] >>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks Tim, >>>>>>>>>>>> >>>>>>>>>>>> I was using branch R7, changed to master, it builds now. >>>>>>>>>>>> >>>>>>>>>>>> Now I have updated my project to OSGi 7 with Transaction Control, >>>>>>>>>>>> how do I deploy to Karaf? >>>>>>>>>>>> i.e., what bundles/features do I need? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Alex soto >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On May 17, 2018, at 2:08 PM, Tim Ward <[email protected] >>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Alex, >>>>>>>>>>>>> >>>>>>>>>>>>> Bnd 4.0.0 was only released last Sunday, but this should have >>>>>>>>>>>>> been changed yesterday in this commit >>>>>>>>>>>>> https://github.com/osgi/osgi.enroute/commit/9f9857c3d317cd08a7aaf7327c1904676299f9ee >>>>>>>>>>>>> >>>>>>>>>>>>> <https://github.com/osgi/osgi.enroute/commit/9f9857c3d317cd08a7aaf7327c1904676299f9ee> >>>>>>>>>>>>> to make sure enRoute kept building. >>>>>>>>>>>>> >>>>>>>>>>>>> EnRoute is automatically pushed to the sonatype OSGi nexus >>>>>>>>>>>>> repository, so is it possible that you’re running offline, or >>>>>>>>>>>>> firewalled from the repo? You should be able to force snapshot >>>>>>>>>>>>> updates from the Maven command line. >>>>>>>>>>>>> >>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Tim >>>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>> >>>>>>>>>>>>> On 17 May 2018, at 18:26, Alex Soto <[email protected] >>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Allright, I am trying to follow the EnRoute tutorial. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am getting this error: >>>>>>>>>>>>>> >>>>>>>>>>>>>> [ERROR] Plugin biz.aQute.bnd:bnd-maven-plugin:4.0.0-SNAPSHOT or >>>>>>>>>>>>>> one of its dependencies could not be resolved: Could not find >>>>>>>>>>>>>> artifact biz.aQute.bnd:bnd-maven-plugin:jar:4.0.0-SNAPSHOT in >>>>>>>>>>>>>> Bnd Snapshots >>>>>>>>>>>>>> (https://bndtools.ci.cloudbees.com/job/bnd.master/lastSuccessfulBuild/artifact/dist/bundles/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> <https://bndtools.ci.cloudbees.com/job/bnd.master/lastSuccessfulBuild/artifact/dist/bundles/>) >>>>>>>>>>>>>> -> [Help 1] >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any idea (time frame) when this will move from SNAPSHOT >>>>>>>>>>>>>> dependencies? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Alex soto >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On May 17, 2018, at 11:08 AM, Tim Ward <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is highly unlikely that you’ll hit the same issues. The >>>>>>>>>>>>>>> transaction control resource provider uses the >>>>>>>>>>>>>>> DataSourceFactory directly to create a DataSource (either >>>>>>>>>>>>>>> progamatically using a factory service or via config admin) >>>>>>>>>>>>>>> that enlists itself in the ongoing transaction. This means that >>>>>>>>>>>>>>> the answer to your question is “with Transaction Control you >>>>>>>>>>>>>>> don’t have to do that because it does it automatically” >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you want to use XA transactions then the only requirement is >>>>>>>>>>>>>>> that the DataSourceFactory can produce an XADataSource, >>>>>>>>>>>>>>> otherwise it just uses the standard JDBC API to >>>>>>>>>>>>>>> commit/rollback. If your DataSourceFactory doesn’t support XA >>>>>>>>>>>>>>> then use the local resource provider implementation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 17 May 2018, at 15:17, Alex Soto <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I will take a look at these examples. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, I think that if I cannot get a MariaDB DataSource >>>>>>>>>>>>>>>> that supports transactions, then it will still not work, right? >>>>>>>>>>>>>>>> If the examples use H2 database, I still may get different >>>>>>>>>>>>>>>> results when I change to MariaDB, and I will find myself in >>>>>>>>>>>>>>>> the same spot as of now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So, the question remains about what is the correct way how to >>>>>>>>>>>>>>>> register a transaction aware MariaDB DataSource. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Alex soto >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On May 17, 2018, at 1:46 AM, Tim Ward <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The best place to start when looking for OSGi R7 examples is >>>>>>>>>>>>>>>>> the enRoute Project. It contains Maven Archetypes, examples >>>>>>>>>>>>>>>>> and worked tutorials for building applications using R7 >>>>>>>>>>>>>>>>> specifications. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://enroute.osgi.org <https://enroute.osgi.org/> >>>>>>>>>>>>>>>>> <https://enroute.osgi.org/ <https://enroute.osgi.org/>> >>>>>>>>>>>>>>>>> <https://enroute.osgi.org/Tutorial/ >>>>>>>>>>>>>>>>> <https://enroute.osgi.org/Tutorial/>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Most of the projects in use are just new versions of long >>>>>>>>>>>>>>>>> established OSGi implementations from Aries and Felix. The >>>>>>>>>>>>>>>>> majority of them are already released and in Maven Central. >>>>>>>>>>>>>>>>> Those that are still in the process of releasing (pretty much >>>>>>>>>>>>>>>>> just the JAX-RS whiteboard) are available in the Apache >>>>>>>>>>>>>>>>> Snapshots repository. I am not aware of any implementations >>>>>>>>>>>>>>>>> that require R7 framework features, so all of them should run >>>>>>>>>>>>>>>>> on Karaf. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 16 May 2018, at 22:25, Alex Soto <[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I agree, it s very frustrating and time consuming. Almost >>>>>>>>>>>>>>>>>> impossible to get it right. >>>>>>>>>>>>>>>>>> I may try the OSGi R7, but I am not sure of its adoption >>>>>>>>>>>>>>>>>> level at this time, availability of bundles, examples, >>>>>>>>>>>>>>>>>> support by Karaf, etc. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Anyway, back to my current stack. I only see one DataSource >>>>>>>>>>>>>>>>>> being registered: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> karaf@root()> service:list DataSource >>>>>>>>>>>>>>>>>> [javax.sql.DataSource] >>>>>>>>>>>>>>>>>> ---------------------- >>>>>>>>>>>>>>>>>> databaseName = responder >>>>>>>>>>>>>>>>>> dataSourceName = responder >>>>>>>>>>>>>>>>>> osgi.jdbc.driver.name = mariadb >>>>>>>>>>>>>>>>>> osgi.jndi.service.name = responder >>>>>>>>>>>>>>>>>> service.bundleid = 14 >>>>>>>>>>>>>>>>>> service.factoryPid = org.ops4j.datasource >>>>>>>>>>>>>>>>>> service.id <http://service.id/> <http://service.id/ >>>>>>>>>>>>>>>>>> <http://service.id/>> <http://service.id/ >>>>>>>>>>>>>>>>>> <http://service.id/>>= 194 >>>>>>>>>>>>>>>>>> service.pid = >>>>>>>>>>>>>>>>>> org.ops4j.datasource.feb33f6d-dc46-4bc7-a417-ad6bdd5a6ee5 >>>>>>>>>>>>>>>>>> service.scope = singleton >>>>>>>>>>>>>>>>>> url = jdbc:mariadb:XXXXXX >>>>>>>>>>>>>>>>>> Provided by : >>>>>>>>>>>>>>>>>> OPS4J Pax JDBC Config (14) >>>>>>>>>>>>>>>>>> Used by: >>>>>>>>>>>>>>>>>> Data (135) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Not sure what to do with this. >>>>>>>>>>>>>>>>>> I specified the following in the configuration: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> pool=narayana >>>>>>>>>>>>>>>>>> xa=true >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Alex soto >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On May 16, 2018, at 4:12 PM, Tim Ward <[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The structure of the JNDI name is defined by the JNDI >>>>>>>>>>>>>>>>>>> service specification. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> osgi:service/<interface name>[/<filter>] >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So in this case both of your services should be DataSource >>>>>>>>>>>>>>>>>>> instances, but they should have different filters. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The important thing is to make sure you have an JTA >>>>>>>>>>>>>>>>>>> enlisting DataSource registered as a service (this isn’t >>>>>>>>>>>>>>>>>>> just your normal DataSource), then to build a filter which >>>>>>>>>>>>>>>>>>> selects that. One option for this is to use the enlistment >>>>>>>>>>>>>>>>>>> whiteboard from Aries (not well documented) >>>>>>>>>>>>>>>>>>> https://github.com/apache/aries/tree/trunk/transaction/transaction-jdbc >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> <https://github.com/apache/aries/tree/trunk/transaction/transaction-jdbc> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is a non-trivial thing to do, which is why I keep >>>>>>>>>>>>>>>>>>> mentioning Transaction Control which handles the enlistment >>>>>>>>>>>>>>>>>>> reliably without the layers of services. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 16 May 2018, at 21:57, Alex Soto <[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thank you Tim. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Any idea what the JNDI names would be? >>>>>>>>>>>>>>>>>>>> It is Pax-JDBC creating these JNDI names, so I have no >>>>>>>>>>>>>>>>>>>> idea. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> From the Karaf console: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> karaf@root()> jndi:names >>>>>>>>>>>>>>>>>>>> JNDI Name │ Class Name >>>>>>>>>>>>>>>>>>>> ───────────────────────┼─────────────────────────────────────────────── >>>>>>>>>>>>>>>>>>>> osgi:service/responder │ org.mariadb.jdbc.MySQLDataSource >>>>>>>>>>>>>>>>>>>> osgi:service/jndi │ >>>>>>>>>>>>>>>>>>>> org.apache.karaf.jndi.internal.JndiServiceImpl >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Alex soto >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On May 16, 2018, at 3:48 PM, Tim Ward >>>>>>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Just looking quickly. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> You have the same JNDI name for both JTA and non JTA >>>>>>>>>>>>>>>>>>>>> DataSources. This is clearly wrong as the DataSource >>>>>>>>>>>>>>>>>>>>> cannot simultaneously be enlisted in the Transaction and >>>>>>>>>>>>>>>>>>>>> not enlisted. The comments also indicate a >>>>>>>>>>>>>>>>>>>>> misunderstanding of the purpose of the >>>>>>>>>>>>>>>>>>>>> non-jta-datasource, which absolutely is used with JTA >>>>>>>>>>>>>>>>>>>>> EntityManagers (for things like sequence allocation and >>>>>>>>>>>>>>>>>>>>> out of band optimisations). You really do need to have >>>>>>>>>>>>>>>>>>>>> both and they do need to behave differently. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> At a guess your DataSource is not enlisted with the >>>>>>>>>>>>>>>>>>>>> transaction manager present in the system. This usually >>>>>>>>>>>>>>>>>>>>> happens by configuring a (otherwise invisible) DataSource >>>>>>>>>>>>>>>>>>>>> wrapper There is nothing forcing you to make this happen >>>>>>>>>>>>>>>>>>>>> (or checking that it does) hence your transactions would >>>>>>>>>>>>>>>>>>>>> be broken. This is one of the several reasons I try to >>>>>>>>>>>>>>>>>>>>> direct people to Transaction Control where the model >>>>>>>>>>>>>>>>>>>>> actively pushes you toward transactions that actually >>>>>>>>>>>>>>>>>>>>> work, rather than hiding all the magic behind an >>>>>>>>>>>>>>>>>>>>> annotation. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hopefully this gives you some clues as to what might be >>>>>>>>>>>>>>>>>>>>> wrong. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 16 May 2018, at 21:34, Jean-Baptiste Onofré >>>>>>>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected] >>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Are you sure about your code ? Flush looks weird to me >>>>>>>>>>>>>>>>>>>>>> and it seems you don't use container managed transaction. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>> JB >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 16/05/2018 21:08, Alex Soto wrote: >>>>>>>>>>>>>>>>>>>>>>> Yes, same result. I even tried with Narayana >>>>>>>>>>>>>>>>>>>>>>> Transaction Manager, and same result. >>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>> Alex soto >>>>>>>>>>>>>>>>>>>>>>>> On May 16, 2018, at 2:56 PM, Jean-Baptiste Onofré >>>>>>>>>>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>><mailto:[email protected] >>>>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Same behavior with RequiresNew ? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>> JB >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 16/05/2018 19:44, Alex Soto wrote: >>>>>>>>>>>>>>>>>>>>>>>>> With Karaf version 4.2.0, Rollback is not working >>>>>>>>>>>>>>>>>>>>>>>>> with MariaDB and InnoDB tables. >>>>>>>>>>>>>>>>>>>>>>>>> I deployed these features (from Karaf’s enterprise >>>>>>>>>>>>>>>>>>>>>>>>> repository): >>>>>>>>>>>>>>>>>>>>>>>>> <feature>aries-blueprint</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>transaction</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>jndi</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>jdbc</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>jpa</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>pax-jdbc-mariadb</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>pax-jdbc-config</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>pax-jdbc-pool-dbcp2</feature> >>>>>>>>>>>>>>>>>>>>>>>>> <feature>hibernate</feature> >>>>>>>>>>>>>>>>>>>>>>>>> My Data Source is configured in the file >>>>>>>>>>>>>>>>>>>>>>>>> /org.ops4j.datasource-responder.cfg/ >>>>>>>>>>>>>>>>>>>>>>>>> osgi.jdbc.driver.name = mariadb >>>>>>>>>>>>>>>>>>>>>>>>> dataSourceName=responder >>>>>>>>>>>>>>>>>>>>>>>>> url >>>>>>>>>>>>>>>>>>>>>>>>> = >>>>>>>>>>>>>>>>>>>>>>>>> jdbc:mariadb://mariadb.local:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true&autocommit=false >>>>>>>>>>>>>>>>>>>>>>>>> user=XXXX >>>>>>>>>>>>>>>>>>>>>>>>> password=XXXX >>>>>>>>>>>>>>>>>>>>>>>>> databaseName=responder >>>>>>>>>>>>>>>>>>>>>>>>> #Pool Config >>>>>>>>>>>>>>>>>>>>>>>>> pool=dbcp2 >>>>>>>>>>>>>>>>>>>>>>>>> xa=true >>>>>>>>>>>>>>>>>>>>>>>>> My persistence.xml: >>>>>>>>>>>>>>>>>>>>>>>>> <persistence version="2.0" >>>>>>>>>>>>>>>>>>>>>>>>> xmlns="http://java.sun.com/xml/ns/persistence"; >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence >>>>>>>>>>>>>>>>>>>>>>>>> http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd";> >>>>>>>>>>>>>>>>>>>>>>>>> <persistence-unit >>>>>>>>>>>>>>>>>>>>>>>>> name="responderPersistenUnit" transaction-type="JTA"> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider> >>>>>>>>>>>>>>>>>>>>>>>>> <!-- Only used when transaction-type=JTA >>>>>>>>>>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)</jta-data-source> >>>>>>>>>>>>>>>>>>>>>>>>> <!-- Only used when >>>>>>>>>>>>>>>>>>>>>>>>> transaction-type=RESOURCE_LOCAL --> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> <non-jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)</non-jta-data-source> >>>>>>>>>>>>>>>>>>>>>>>>> <properties> >>>>>>>>>>>>>>>>>>>>>>>>> <property name=“hibernate.dialect" >>>>>>>>>>>>>>>>>>>>>>>>> value="org.hibernate.dialect.MySQL5Dialect" /> >>>>>>>>>>>>>>>>>>>>>>>>> <property name="hibernate.show_sql" >>>>>>>>>>>>>>>>>>>>>>>>> value="true" /> >>>>>>>>>>>>>>>>>>>>>>>>> <property name="hibernate.format_sql" >>>>>>>>>>>>>>>>>>>>>>>>> value="true" /> >>>>>>>>>>>>>>>>>>>>>>>>> <property >>>>>>>>>>>>>>>>>>>>>>>>> name="hibernate.hbm2ddl.auto" value="none"/> >>>>>>>>>>>>>>>>>>>>>>>>> </properties> >>>>>>>>>>>>>>>>>>>>>>>>> </persistence-unit> >>>>>>>>>>>>>>>>>>>>>>>>> </persistence> >>>>>>>>>>>>>>>>>>>>>>>>> My blueprint.xml: >>>>>>>>>>>>>>>>>>>>>>>>> <blueprint >>>>>>>>>>>>>>>>>>>>>>>>> xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; >>>>>>>>>>>>>>>>>>>>>>>>> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0"; >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0"; >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 >>>>>>>>>>>>>>>>>>>>>>>>> https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";> >>>>>>>>>>>>>>>>>>>>>>>>> <jpa:enable /> >>>>>>>>>>>>>>>>>>>>>>>>> <tx:enable /> >>>>>>>>>>>>>>>>>>>>>>>>> <bean id="userService" >>>>>>>>>>>>>>>>>>>>>>>>> class="org.data.impl.UserServiceImpl" /> >>>>>>>>>>>>>>>>>>>>>>>>> <service ref="userService" >>>>>>>>>>>>>>>>>>>>>>>>> interface="org.data.UserService" /> >>>>>>>>>>>>>>>>>>>>>>>>> </blueprint> >>>>>>>>>>>>>>>>>>>>>>>>> For testing I throw exception in my DAO: >>>>>>>>>>>>>>>>>>>>>>>>> @Transactional(REQUIRED) >>>>>>>>>>>>>>>>>>>>>>>>> public void addUser(User user) { >>>>>>>>>>>>>>>>>>>>>>>>> em.persist(user); >>>>>>>>>>>>>>>>>>>>>>>>> em.flush(); >>>>>>>>>>>>>>>>>>>>>>>>> throw new RuntimeException("On Purpose"); >>>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>>> I expect the record not to be in the table due to >>>>>>>>>>>>>>>>>>>>>>>>> rollback of the transaction, but it still shows up in >>>>>>>>>>>>>>>>>>>>>>>>> my database table. >>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>> Alex soto
