Maybe try upgrading config admin also? There are a lot of new capabilities ds takes advantage of.
David Jencks Sent from my iPhone > On May 18, 2018, at 11:07 AM, Alex Soto <[email protected]> wrote: > > Tried adding Felix SCR 2.1.0, but it looks like it is not as simple: > > org.osgi.framework.ServiceException: Service factory exception: > org/osgi/service/cm/ManagedService > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350) > ~[?:?] > at org.apache.felix.framework.Felix.getService(Felix.java:3737) ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) > ~[?:?] > at > org.apache.felix.metatype.internal.ManagedServiceTracker.addingService(ManagedServiceTracker.java:52) > ~[?:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) > ~[?:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) > ~[?:?] > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > ~[?:?] > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) ~[?:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) > ~[?:?] > at > org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) > ~[?:?] > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) > ~[?:?] > at org.apache.felix.framework.Felix.registerService(Felix.java:3587) > ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) > ~[?:?] > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322) > ~[?:?] > at > org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:120) > ~[?:?] > at org.apache.felix.scr.impl.Activator.start(Activator.java:100) ~[?:?] > at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697) > ~[?:?] > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) > ~[?:?] > at org.apache.felix.framework.Felix.startBundle(Felix.java:2146) ~[?:?] > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) > ~[?:?] > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) > ~[?:?] > at > org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:161) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1116) > ~[?:?] > at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:996) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025) > ~[?:?] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964) > ~[?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > ~[?:?] > at java.lang.Thread.run(Thread.java:748) [?:?] > Caused by: java.lang.NoClassDefFoundError: org/osgi/service/cm/ManagedService > at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?] > at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) > ~[?:?] > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?] > at > org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > ~[?:?] > ... 33 more > Caused by: java.lang.ClassNotFoundException: > org.osgi.service.cm.ManagedService not found by org.apache.felix.scr [67] > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) > ~[?:?] > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?] > at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?] > at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) > ~[?:?] > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) > ~[?:?] > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?] > at > org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47) > ~[?:?] > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > ~[?:?] > ... 33 more > > > > Best regards, > Alex soto > > > > >> On May 18, 2018, at 12:46 PM, Jean-Baptiste Onofré <[email protected]> wrote: >> >> 4.2.1-SNAPSHOT already updated to DS 1.4 (SCR 2.1.0) (ready on one of my >> branch). >> >> Regards >> JB >> >>> On 18/05/2018 17:50, Alex Soto wrote: >>> Great, I solved the Eclipse problem. Thanks. >>> Yes, Karaf provides DS 1.3, but no DS 1.4 out off the box. >>> Maybe this is available from Aries? >>> Best regards, >>> Alex soto >>>> On May 18, 2018, at 11:18 AM, Tim Ward <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>> Answers inline: >>>> >>>> Sent from my iPhone >>>> >>>>> On 18 May 2018, at 16:55, Alex Soto <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Thank you Tim for the very detailed explanation. >>>>> There are two problems I don’t know how to resolve: >>>>> >>>>> 1- BND generates this for my bundle: >>>>> >>>>> Require-Capability: >>>>> osgi.extender;filter:="(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))” >>>>> >>>>> This is because I use the @Component and @Reference annotations. This is >>>>> strange, since I should be using OSGi R7, so I am not sure why it is >>>>> saying 1.3.0. Now when try to run in Karaf, even though I am >>>>> installing/scr/feature, it fails with unresolved requirement. >>>> >>>> So in the absence of information to the contrary this requirement is added >>>> based on your usage of Declarative Services features. If you use DS 1.3 >>>> features then DS 1.3 will be required. >>>> >>>> Since R7 added the bundle requirement annotations the @Component >>>> annotation has been annotated to require DS at the current spec version >>>> (this gives a more consistent behaviour than bnd’s heuristics). At a guess >>>> you are picking up a 1.3 requirement because you have the 1.3 annotations >>>> ahead of the 1.4 annotations on your classpath, but it could be triggered >>>> by other things too. On the other hand this isn’t actually a problem as >>>> the requirement is still satisfied by DS 1.4 and both versions will work >>>> for you at runtime. >>>> >>>> The Karaf scr feature really should be providing SCR 1.3 (which is >>>> required by the spec to provide the extender capability. That has been the >>>> current version of the spec for three years, and has been provided by >>>> Felix for at least 6 releases. I’d be pretty shocked if DS 1.3 wasn’t >>>> supported. You may need help from a more Karaf focussed person to confirm >>>> this. >>>> >>>>> >>>>> Since I could not find OSGi R7 in public Maven Repos, I followed EnRoute >>>>> depending on: >>>>> <dependency> >>>>> <groupId>org.osgi.enroute</groupId> >>>>> <artifactId>osgi-api</artifactId> >>>>> <version>7.0.0-SNAPSHOT</version> >>>>> <type>pom</type> >>>>> <scope>provided</scope> >>>>> </dependency> >>>>> <dependency> >>>>> <groupId>org.osgi.enroute</groupId> >>>>> <artifactId>enterprise-api</artifactId> >>>>> <version>7.0.0-SNAPSHOT</version> >>>>> <type>pom</type> >>>>> <scope>provided</scope> >>>>> </dependency> >>>> >>>> There’s no problem with you using these. On the other hand the OSGi API >>>> aggregations you are looking for are: >>>> >>>> https://mvnrepository.com/artifact/org.osgi/osgi.core >>>> >>>> https://mvnrepository.com/artifact/org.osgi/osgi.cmpn >>>> >>>> You can also find the individual specs under the org.osgi group id if you >>>> want to use a smaller hammer :) >>>> >>>>> >>>>> 2- This is minor, and I see it also in the EnRoute project. While the >>>>> Maven build succeeds, Eclipse BND plugin shows 2 errors: >>>>> >>>>> The default package '.' is not permitted by the Import-Package >>>>> syntax. This can be caused by compile errors in Eclipse >>>>> because Eclipse creates valid class files regardless of compile >>>>> errors. The following package(s) import from the default >>>>> package [org.enquery.encryptedquery.responder.data.service.impl] >>>>> >>>>> (biz.aQute.bnd:bnd-maven-plugin:4.0.0:bnd-process:default:process-classes)pom.xml/encryptedquery-responder-dataline >>>>> 0Maven Build Participant Problem >>>>> >>>>> The project was not built since its build path is incomplete. >>>>> Cannot find the class file for javax.persistence.EntityManager. >>>>> Fix the build path then try building this >>>>> projectencryptedquery-responder-dataUnknownJava Problem >>>>> >>>>> >>>> >>>> As the message suggests, this usually occurs when Eclipse has build errors >>>> for the project. Specifically in this case you seem to be building against >>>> a project which exposes the EntityManager interface somehow, but you don’t >>>> have the JPA API in your compile dependencies (normally these would come >>>> come in transitively from the project you depend on). >>>> >>>> I hope this helps, >>>> >>>> Tim >>>> >>>>> >>>>> >>>>> Best regards, >>>>> Alex soto >>>>> >>>>> >>>>> >>>>> >>>>>> On May 18, 2018, at 5:23 AM, Tim Ward <[email protected] >>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Thanks Tim, >>>>>>> >>>>>>> I was using branch R7, changed to master, it builds now. >>>>>>> >>>>>>> Now I have updated my project to OSGi 7 with Transaction Control, how >>>>>>> do I deploy to Karaf? >>>>>>> i.e., what bundles/features do I need? >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Alex soto >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On May 17, 2018, at 2:08 PM, Tim Ward <[email protected] >>>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> Allright, I am trying to follow the EnRoute tutorial. >>>>>>>>> >>>>>>>>> I am getting this error: >>>>>>>>> >>>>>>>>> [ERROR] Plugin biz.aQute.bnd:bnd-maven-plugin:4.0.0-SNAPSHOT or one >>>>>>>>> of its dependencies could not be resolved: Could not find artifact >>>>>>>>> biz.aQute.bnd:bnd-maven-plugin:jar:4.0.0-SNAPSHOT in Bnd Snapshots >>>>>>>>> (https://bndtools.ci.cloudbees.com/job/bnd.master/lastSuccessfulBuild/artifact/dist/bundles/) >>>>>>>>> -> [Help 1] >>>>>>>>> >>>>>>>>> >>>>>>>>> Any idea (time frame) when this will move from SNAPSHOT dependencies? >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Alex soto >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On May 17, 2018, at 11:08 AM, Tim Ward <[email protected] >>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>> It is highly unlikely that you’ll hit the same issues. The >>>>>>>>>> transaction control resource provider uses the DataSourceFactory >>>>>>>>>> directly to create a DataSource (either progamatically using a >>>>>>>>>> factory service or via config admin) that enlists itself in the >>>>>>>>>> ongoing transaction. This means that the answer to your question is >>>>>>>>>> “with Transaction Control you don’t have to do that because it does >>>>>>>>>> it automatically” >>>>>>>>>> >>>>>>>>>> If you want to use XA transactions then the only requirement is that >>>>>>>>>> the DataSourceFactory can produce an XADataSource, otherwise it just >>>>>>>>>> uses the standard JDBC API to commit/rollback. If your >>>>>>>>>> DataSourceFactory doesn’t support XA then use the local resource >>>>>>>>>> provider implementation. >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> Tim >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>>> On 17 May 2018, at 15:17, Alex Soto <[email protected] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> I will take a look at these examples. >>>>>>>>>>> >>>>>>>>>>> However, I think that if I cannot get a MariaDB DataSource that >>>>>>>>>>> supports transactions, then it will still not work, right? >>>>>>>>>>> If the examples use H2 database, I still may get different results >>>>>>>>>>> when I change to MariaDB, and I will find myself in the same spot >>>>>>>>>>> as of now. >>>>>>>>>>> >>>>>>>>>>> So, the question remains about what is the correct way how to >>>>>>>>>>> register a transaction aware MariaDB DataSource. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Alex soto >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On May 17, 2018, at 1:46 AM, Tim Ward <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> 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/Tutorial/> >>>>>>>>>>>> >>>>>>>>>>>> Most of the projects in use are just new versions of long >>>>>>>>>>>> established OSGi implementations from Aries and Felix. The >>>>>>>>>>>> majority of them are already released and in Maven Central. Those >>>>>>>>>>>> that are still in the process of releasing (pretty much just the >>>>>>>>>>>> JAX-RS whiteboard) are available in the Apache Snapshots >>>>>>>>>>>> repository. I am not aware of any implementations that require R7 >>>>>>>>>>>> framework features, so all of them should run on Karaf. >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> >>>>>>>>>>>> Tim >>>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>>> On 16 May 2018, at 22:25, Alex Soto <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> 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/>= 194 >>>>>>>>>>>>> service.pid = >>>>>>>>>>>>> org.ops4j.datasource.feb33f6d-dc46-4bc7-a417-ad6bdd5a6ee5 >>>>>>>>>>>>> service.scope = singleton >>>>>>>>>>>>> url = jdbc:mariadb:XXXXXX >>>>>>>>>>>>> Provided by : >>>>>>>>>>>>> OPS4J Pax JDBC Config (14) >>>>>>>>>>>>> Used by: >>>>>>>>>>>>> Data (135) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure what to do with this. >>>>>>>>>>>>> I specified the following in the configuration: >>>>>>>>>>>>> >>>>>>>>>>>>> pool=narayana >>>>>>>>>>>>> xa=true >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Alex soto >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On May 16, 2018, at 4:12 PM, Tim Ward <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you Tim. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any idea what the JNDI names would be? >>>>>>>>>>>>>>> It is Pax-JDBC creating these JNDI names, so I have no idea. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From the Karaf console: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> karaf@root()> jndi:names >>>>>>>>>>>>>>> JNDI Name │ Class Name >>>>>>>>>>>>>>> ───────────────────────┼─────────────────────────────────────────────── >>>>>>>>>>>>>>> osgi:service/responder │ org.mariadb.jdbc.MySQLDataSource >>>>>>>>>>>>>>> osgi:service/jndi │ >>>>>>>>>>>>>>> org.apache.karaf.jndi.internal.JndiServiceImpl >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Alex soto >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On May 16, 2018, at 3:48 PM, Tim Ward <[email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Just looking quickly. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You have the same JNDI name for both JTA and non JTA >>>>>>>>>>>>>>>> DataSources. This is clearly wrong as the DataSource cannot >>>>>>>>>>>>>>>> simultaneously be enlisted in the Transaction and not >>>>>>>>>>>>>>>> enlisted. The comments also indicate a misunderstanding of the >>>>>>>>>>>>>>>> purpose of the non-jta-datasource, which absolutely is used >>>>>>>>>>>>>>>> with JTA EntityManagers (for things like sequence allocation >>>>>>>>>>>>>>>> and out of band optimisations). You really do need to have >>>>>>>>>>>>>>>> both and they do need to behave differently. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At a guess your DataSource is not enlisted with the >>>>>>>>>>>>>>>> transaction manager present in the system. This usually >>>>>>>>>>>>>>>> happens by configuring a (otherwise invisible) DataSource >>>>>>>>>>>>>>>> wrapper There is nothing forcing you to make this happen (or >>>>>>>>>>>>>>>> checking that it does) hence your transactions would be >>>>>>>>>>>>>>>> broken. This is one of the several reasons I try to direct >>>>>>>>>>>>>>>> people to Transaction Control where the model actively pushes >>>>>>>>>>>>>>>> you toward transactions that actually work, rather than hiding >>>>>>>>>>>>>>>> all the magic behind an annotation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hopefully this gives you some clues as to what might be wrong. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 16 May 2018, at 21:34, Jean-Baptiste Onofré >>>>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Are you sure about your code ? Flush looks weird to me and it >>>>>>>>>>>>>>>>> seems you don't use container managed transaction. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> JB >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 16/05/2018 21:08, Alex Soto wrote: >>>>>>>>>>>>>>>>>> Yes, same result. I even tried with Narayana Transaction >>>>>>>>>>>>>>>>>> Manager, and same result. >>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>> Alex soto >>>>>>>>>>>>>>>>>>> On May 16, 2018, at 2:56 PM, Jean-Baptiste Onofré >>>>>>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>>>>>> <mailto:[email protected]><mailto:[email protected]>> 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 >
