karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: MariaDB/JPA Transaction rollback not working
Date Mon, 21 May 2018 19:39:13 GMT
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é <jb@nanthrax.net 
>> <mailto:jb@nanthrax.net>> 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 <alex.soto@envieta.com 
>>> <mailto:alex.soto@envieta.com><mailto:alex.soto@envieta.com>> 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 <tim.ward@paremus.com 
>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com>> 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é <jb@nanthrax.net 
>>>>> <mailto:jb@nanthrax.net><mailto:jb@nanthrax.net>> 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é 
>>>>>>>> <jb@nanthrax.net 
>>>>>>>> <mailto:jb@nanthrax.net><mailto:jb@nanthrax.net> 
>>>>>>>> <mailto:jb@nanthrax.net>> 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 <tim.ward@paremus.com 
>>>>>>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com> 
>>>>>>>>>> <mailto:tim.ward@paremus.com> <mailto:tim.ward@paremus.com>> 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Answers inline:
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On 18 May 2018, at 16:55, Alex Soto <alex.soto@envieta.com 
>>>>>>>>>> <mailto:alex.soto@envieta.com><mailto:alex.soto@envieta.com> 
>>>>>>>>>> <mailto:alex.soto@envieta.com> <mailto:alex.soto@envieta.com>> 
>>>>>>>>>> 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.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 <tim.ward@paremus.com 
>>>>>>>>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com> 
>>>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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 <alex.soto@envieta.com 
>>>>>>>>>>>> <mailto:alex.soto@envieta.com><mailto:alex.soto@envieta.com> 
>>>>>>>>>>>> <mailto:alex.soto@envieta.com>> 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 
>>>>>>>>>>>>>> <tim.ward@paremus.com 
>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com> 
>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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 <alex.soto@envieta.com 
>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com><mailto:alex.soto@envieta.com> 
>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com>> 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 
>>>>>>>>>>>>>>>> <tim.ward@paremus.com 
>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com> 
>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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 
>>>>>>>>>>>>>>>> <alex.soto@envieta.com 
>>>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com><mailto:alex.soto@envieta.com> 
>>>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com>> 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 
>>>>>>>>>>>>>>>>>> <tim.ward@paremus.com 
>>>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com> 
>>>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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/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 
>>>>>>>>>>>>>>>>>> <alex.soto@envieta.com 
>>>>>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com><mailto:alex.soto@envieta.com> 
>>>>>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com>> 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/>= 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 
>>>>>>>>>>>>>>>>>>>> <tim.ward@paremus.com 
>>>>>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com> 
>>>>>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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 
>>>>>>>>>>>>>>>>>>>> <alex.soto@envieta.com 
>>>>>>>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com><mailto:alex.soto@envieta.com> 
>>>>>>>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com>> 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 
>>>>>>>>>>>>>>>>>>>>>> <tim.ward@paremus.com 
>>>>>>>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com><mailto:tim.ward@paremus.com> 
>>>>>>>>>>>>>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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é 
>>>>>>>>>>>>>>>>>>>>>>> <jb@nanthrax.net 
>>>>>>>>>>>>>>>>>>>>>>> <mailto:jb@nanthrax.net><mailto:jb@nanthrax.net> 
>>>>>>>>>>>>>>>>>>>>>>> <mailto:jb@nanthrax.net>> 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é <jb@nanthrax.net 
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:jb@nanthrax.net><mailto:jb@nanthrax.net> <mailto:jb@nanthrax.net><mailto:jb@nanthrax.net>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 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
> 


Mime
View raw message