That actually doesn’t look like a fatal exception, all that’s happening is that Metatype is unable to retrieve the ManagedService from SCR. It may indicate a problem down the line with receiving config though.
Tim Sent from my iPhone > On 19 May 2018, at 03:36, David Jencks <david.a.jen...@gmail.com> wrote: > > 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 <alex.s...@envieta.com> 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é <j...@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.w...@paremus.com >>>>> <mailto:tim.w...@paremus.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Answers inline: >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 18 May 2018, at 16:55, Alex Soto <alex.s...@envieta.com >>>>>> <mailto:alex.s...@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.w...@paremus.com >>>>>>> <mailto:tim.w...@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.s...@envieta.com >>>>>>>> <mailto:alex.s...@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.w...@paremus.com >>>>>>>>> <mailto:tim.w...@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.s...@envieta.com >>>>>>>>>> <mailto:alex.s...@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.w...@paremus.com >>>>>>>>>>> <mailto:tim.w...@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.s...@envieta.com >>>>>>>>>>>> <mailto:alex.s...@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.w...@paremus.com >>>>>>>>>>>>> <mailto:tim.w...@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/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.s...@envieta.com >>>>>>>>>>>>>> <mailto:alex.s...@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/>= 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.w...@paremus.com >>>>>>>>>>>>>>> <mailto:tim.w...@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.s...@envieta.com >>>>>>>>>>>>>>>> <mailto:alex.s...@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.w...@paremus.com >>>>>>>>>>>>>>>>> <mailto:tim.w...@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é >>>>>>>>>>>>>>>>>> <j...@nanthrax.net <mailto:j...@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é >>>>>>>>>>>>>>>>>>>> <j...@nanthrax.net >>>>>>>>>>>>>>>>>>>> <mailto:j...@nanthrax.net><mailto:j...@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 >>
