From user-return-18605-archive-asf-public=cust-asf.ponee.io@karaf.apache.org Mon May 21 21:39:32 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6F44418063A for ; Mon, 21 May 2018 21:39:30 +0200 (CEST) Received: (qmail 31178 invoked by uid 500); 21 May 2018 19:39:29 -0000 Mailing-List: contact user-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@karaf.apache.org Delivered-To: mailing list user@karaf.apache.org Received: (qmail 31168 invoked by uid 99); 21 May 2018 19:39:29 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 May 2018 19:39:29 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id D7ADE1A026A for ; Mon, 21 May 2018 19:39:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, KAM_SHORT=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id DWznTv9S8Gsu for ; Mon, 21 May 2018 19:39:20 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 4FF705F217 for ; Mon, 21 May 2018 19:39:20 +0000 (UTC) X-Originating-IP: 82.238.224.4 Received: from [192.168.134.26] (bre91-1-82-238-224-4.fbx.proxad.net [82.238.224.4]) (Authenticated sender: jb@nanthrax.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 2CC4960003 for ; Mon, 21 May 2018 21:39:14 +0200 (CEST) Subject: Re: MariaDB/JPA Transaction rollback not working To: user@karaf.apache.org References: <975389E7-1766-42D8-A42D-F096EFFBF408@envieta.com> <821F4411-4742-45D6-8AB5-893D1FC27A9E@paremus.com> <9D1A9178-39AD-4F6F-876D-8AFA838377FE@paremus.com> <553CFABC-6C09-4990-9E33-3C5D2527FA2E@envieta.com> <75DE775F-7D76-40D5-86CA-9F5EC6FDBB1E@paremus.com> <08BE597F-CC91-4EA6-91D5-FFAA39486414@envieta.com> <97F07745-ECC4-4FF9-AAA7-7E62456FF774@paremus.com> <17788AF1-FAC8-4DD9-B19C-3DC2C03AF671@envieta.com> <49bc6876-34e2-b587-5d17-179c4c83eb15@nanthrax.net> <75F1F9A8-1290-4C16-9D52-A678792E49D4@envieta.com> <47f49684-70f1-5bb8-9f14-7e03f43a5ae4@nanthrax.net> <5587127F-14A2-4F47-A300-4AF331C2D9D0@envieta.com> From: =?UTF-8?Q?Jean-Baptiste_Onofr=c3=a9?= Message-ID: Date: Mon, 21 May 2018 21:39:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5587127F-14A2-4F47-A300-4AF331C2D9D0@envieta.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit By the way: https://github.com/apache/karaf/pull/509 This is my PR containing the SCR 2.1.0 update (I gonna merge once Jenkins is OK). Regards JB On 21/05/2018 20:59, Alex Soto wrote: > 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é > > 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 >> > 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 >>>> > 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.transaction.control >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 19 May 2018, at 07:58, Jean-Baptiste Onofré >>>> > 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é >>>>>>>> >>>>>>> >>>>>>>> > 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 >>>>>>>>> >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Answers inline: >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On 18 May 2018, at 16:55, Alex Soto >>>>>>>>> >>>>>>>>>> > >>>>>>>>>> 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: >>>>>>>>>>>       >>>>>>>>>>>         org.osgi.enroute >>>>>>>>>>>         osgi-api >>>>>>>>>>>         7.0.0-SNAPSHOT >>>>>>>>>>>         pom >>>>>>>>>>>         provided >>>>>>>>>>>        >>>>>>>>>>>        >>>>>>>>>>>         org.osgi.enroute >>>>>>>>>>>         enterprise-api >>>>>>>>>>>         7.0.0-SNAPSHOT >>>>>>>>>>>         pom >>>>>>>>>>>         provided >>>>>>>>>>>        >>>>>>>>>> >>>>>>>>>> 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.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 >>>>>>>>>>> >>>>>>>>>>>> > 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.1https://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 >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> examplehttps://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 >>>>>>>>>>>> examplehttps://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. >>>>>>>>>>>> Seehttps://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, >>>>>>>>>>>> seehttps://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 >>>>>>>>>>> >>>>>>>>>>>> > 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Alex, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bnd 4.0.0 was only released last Sunday, but this should >>>>>>>>>>>>>> have been changed yesterday in this >>>>>>>>>>>>>> commithttps://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 >>>>>>>>>>>>> >>>>>>>>>>>>>> > 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/) >>>>>>>>>>>>>>> -> [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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>>>>>> = 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The structure of the JNDI name is defined by the >>>>>>>>>>>>>>>>>>>> JNDI service specification. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> osgi:service/[/] >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > 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é >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > 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é >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> 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): >>>>>>>>>>>>>>>>>>>>>>>>>> aries-blueprint >>>>>>>>>>>>>>>>>>>>>>>>>> transaction >>>>>>>>>>>>>>>>>>>>>>>>>> jndi >>>>>>>>>>>>>>>>>>>>>>>>>> jdbc >>>>>>>>>>>>>>>>>>>>>>>>>> jpa >>>>>>>>>>>>>>>>>>>>>>>>>> pax-jdbc-mariadb >>>>>>>>>>>>>>>>>>>>>>>>>>        pax-jdbc-config >>>>>>>>>>>>>>>>>>>>>>>>>> pax-jdbc-pool-dbcp2 >>>>>>>>>>>>>>>>>>>>>>>>>> hibernate >>>>>>>>>>>>>>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>>>   >>>>>>>>>>>>>>>>>>>>>>>>> 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"> >>>>>>>>>>>>>>>>>>>>>>>>>>            >>>>>>>>>>>>>>>>>>>>>>>>> name="responderPersistenUnit" >>>>>>>>>>>>>>>>>>>>>>>>>> transaction-type="JTA"> >>>>>>>>>>>>>>>>>>>>>>>>>>                org.hibernate.jpa.HibernatePersistenceProvider >>>>>>>>>>>>>>>>>>>>>>>>>>             >>>>>>>>>>>>>>>>>>>>>>>>>>                osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder) >>>>>>>>>>>>>>>>>>>>>>>>>>             >>>>>>>>>>>>>>>>>>>>>>>>>>                osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder) >>>>>>>>>>>>>>>>>>>>>>>>>>             >>>>>>>>>>>>>>>>>>>>>>>>>>                    >>>>>>>>>>>>>>>>>>>>>>>>> name=“hibernate.dialect" >>>>>>>>>>>>>>>>>>>>>>>>>> value="org.hibernate.dialect.MySQL5Dialect" /> >>>>>>>>>>>>>>>>>>>>>>>>>>                >>>>>>>>>>>>>>>>>>>>>>>>> name="hibernate.show_sql" value="true" /> >>>>>>>>>>>>>>>>>>>>>>>>>>                >>>>>>>>>>>>>>>>>>>>>>>>> name="hibernate.format_sql" value="true" /> >>>>>>>>>>>>>>>>>>>>>>>>>>                >>>>>>>>>>>>>>>>>>>>>>>>> name="hibernate.hbm2ddl.auto" value="none"/> >>>>>>>>>>>>>>>>>>>>>>>>>>             >>>>>>>>>>>>>>>>>>>>>>>>>>         >>>>>>>>>>>>>>>>>>>>>>>>>>    >>>>>>>>>>>>>>>>>>>>>>>>>> My blueprint.xml: >>>>>>>>>>>>>>>>>>>>>>>>>>   >>>>>>>>>>>>>>>>>>>>>>>>> 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"> >>>>>>>>>>>>>>>>>>>>>>>>>>    >>>>>>>>>>>>>>>>>>>>>>>>>>    >>>>>>>>>>>>>>>>>>>>>>>>>>   >>>>>>>>>>>>>>>>>>>>>>>>> class="org.data.impl.UserServiceImpl" /> >>>>>>>>>>>>>>>>>>>>>>>>>>   >>>>>>>>>>>>>>>>>>>>>>>>> interface="org.data.UserService" /> >>>>>>>>>>>>>>>>>>>>>>>>>>    >>>>>>>>>>>>>>>>>>>>>>>>>> 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 >