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 18:34:07 GMT
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>> 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>> 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>> 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>> 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>> 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>> 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>> 
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> 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 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
>>>>>>>>>>
>>>>>>>>>> • 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
>>>>>>>>>>
>>>>>>>>>> • 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
>>>>>>>>>>
>>>>>>>>>> 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)
>>>>>>>>>>
>>>>>>>>>> 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>> 
>>>>>>>>>> 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>> 
>>>>>>>>>>>> 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 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>> 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>> 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>> 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>> 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/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>> 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/>= 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>> 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>> 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>> 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>> 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>> 
>>>>>>>>>>>>>>>>>>>>>>> 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