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
