karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: MariaDB/JPA Transaction rollback not working
Date Sat, 19 May 2018 05:58:59 GMT
Hi Alex,

I don't think it's a good idea to update only SCR without updating other 
part of Karaf (ClassNotFoundException seems to  come from  a compendium 
package).

I strongly recommend to focus on the current 4.2.0 distribution and 
clearly list the issue to me: I will add a sample (eventually 
identifying the issue).

Please, can you give me an access to your project in order to clearly 
understand the issue (I'm a bit lost in the thread).

NB: for pure BND/EnRoute question, it's better to ask on the bnd mailing 
list IMHO. Thanks !

Regards
JB


On 18/05/2018 20:07, Alex Soto wrote:
> Tried adding Felix SCR 2.1.0, but it looks like it is not as simple:
> 
> org.osgi.framework.ServiceException: Service factory exception: 
> org/osgi/service/cm/ManagedService
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352) 
> ~[?:?]
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) 
> ~[?:?]
> at 
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350) 
> ~[?:?]
> at org.apache.felix.framework.Felix.getService(Felix.java:3737) ~[?:?]
> at 
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) 
> ~[?:?]
> at 
> org.apache.felix.metatype.internal.ManagedServiceTracker.addingService(ManagedServiceTracker.java:52) 
> ~[?:?]
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941) 
> ~[?:?]
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870) 
> ~[?:?]
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) 
> ~[?:?]
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) 
> ~[?:?]
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901) 
> ~[?:?]
> at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) 
> ~[?:?]
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) 
> ~[?:?]
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) 
> ~[?:?]
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) ~[?:?]
> at org.apache.felix.framework.Felix.registerService(Felix.java:3587) ~[?:?]
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322) 
> ~[?:?]
> at 
> org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:120) 
> ~[?:?]
> at org.apache.felix.scr.impl.Activator.start(Activator.java:100) ~[?:?]
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697) 
> ~[?:?]
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) ~[?:?]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2146) ~[?:?]
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) ~[?:?]
> at 
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:161) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1116) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:996) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964) 
> ~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
> ~[?:?]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
> ~[?:?]
> at java.lang.Thread.run(Thread.java:748) [?:?]
> Caused by: java.lang.NoClassDefFoundError: 
> org/osgi/service/cm/ManagedService
> at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) 
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at 
> org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47) 
> ~[?:?]
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) 
> ~[?:?]
> ... 33 more
> Caused by: java.lang.ClassNotFoundException: 
> org.osgi.service.cm.ManagedService not found by org.apache.felix.scr [67]
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) 
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80) 
> ~[?:?]
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053) 
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
> at 
> org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47) 
> ~[?:?]
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) 
> ~[?:?]
> ... 33 more
> 
> 
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On May 18, 2018, at 12:46 PM, Jean-Baptiste Onofré <jb@nanthrax.net 
>> <mailto:jb@nanthrax.net>> wrote:
>>
>> 4.2.1-SNAPSHOT already updated to DS 1.4 (SCR 2.1.0) (ready on one of 
>> my branch).
>>
>> Regards
>> JB
>>
>> On 18/05/2018 17:50, Alex Soto wrote:
>>> Great, I solved the Eclipse problem.  Thanks.
>>> Yes, Karaf provides DS 1.3,  but no DS 1.4 out off the box.
>>> Maybe this is available from Aries?
>>> Best regards,
>>> Alex soto
>>>> On May 18, 2018, at 11:18 AM, Tim Ward <tim.ward@paremus.com 
>>>> <mailto:tim.ward@paremus.com> <mailto:tim.ward@paremus.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Answers inline:
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 18 May 2018, at 16:55, Alex Soto <alex.soto@envieta.com 
>>>> <mailto:alex.soto@envieta.com> <mailto:alex.soto@envieta.com>> wrote:
>>>>
>>>>> Thank you Tim for the very detailed explanation.
>>>>> There are  two problems I don’t know how to resolve:
>>>>>
>>>>> 1- BND generates this for my bundle:
>>>>>
>>>>> Require-Capability: 
>>>>>  osgi.extender;filter:="(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))”
>>>>>
>>>>> This is because I use the @Component and @Reference annotations. 
>>>>>  This is strange, since I should be using OSGi R7, so I am not sure 
>>>>> why it is saying 1.3.0.  Now when try to run in Karaf, even though 
>>>>> I am installing/scr/feature, it fails with unresolved requirement.
>>>>
>>>> So in the absence of information to the contrary this requirement is 
>>>> added based on your usage of Declarative Services features. If you 
>>>> use DS 1.3 features then DS 1.3 will be required.
>>>>
>>>> Since R7 added the bundle requirement annotations the @Component 
>>>> annotation has been annotated to require DS at the current spec 
>>>> version (this gives a more consistent behaviour than bnd’s 
>>>> heuristics). At a guess you are picking up a 1.3 requirement because 
>>>> you have the 1.3 annotations ahead of the 1.4 annotations on your 
>>>> classpath, but it could be triggered by other things too. On the 
>>>> other hand this isn’t actually a problem as the requirement is still 
>>>> satisfied by DS 1.4 and both versions will work for you at runtime.
>>>>
>>>> The Karaf scr feature really should be providing SCR 1.3 (which is 
>>>> required by the spec to provide the extender capability. That has 
>>>> been the current version of the spec for three years, and has been 
>>>> provided by Felix for at least 6 releases. I’d be pretty shocked if 
>>>> DS 1.3 wasn’t supported. You may need help from a more Karaf 
>>>> focussed person to confirm this.
>>>>
>>>>>
>>>>> Since I could not find OSGi R7 in public Maven Repos, I followed 
>>>>> EnRoute depending on:
>>>>>       <dependency>
>>>>>         <groupId>org.osgi.enroute</groupId>
>>>>>         <artifactId>osgi-api</artifactId>
>>>>>         <version>7.0.0-SNAPSHOT</version>
>>>>>         <type>pom</type>
>>>>>         <scope>provided</scope>
>>>>>       </dependency>
>>>>>       <dependency>
>>>>>         <groupId>org.osgi.enroute</groupId>
>>>>>         <artifactId>enterprise-api</artifactId>
>>>>>         <version>7.0.0-SNAPSHOT</version>
>>>>>         <type>pom</type>
>>>>>         <scope>provided</scope>
>>>>>       </dependency>
>>>>
>>>> There’s no problem with you using these. On the other hand the OSGi 
>>>> API aggregations you are looking for are:
>>>>
>>>> https://mvnrepository.com/artifact/org.osgi/osgi.core
>>>>
>>>> https://mvnrepository.com/artifact/org.osgi/osgi.cmpn
>>>>
>>>> You can also find the individual specs under the org.osgi group id 
>>>> if you want to use a smaller hammer :)
>>>>
>>>>>
>>>>> 2- This is minor, and I see it also in the EnRoute project. While 
>>>>> the Maven build succeeds, Eclipse BND plugin shows 2 errors:
>>>>>
>>>>>    The default package '.' is not permitted by the Import-Package
>>>>>    syntax. This can be caused by compile errors in Eclipse
>>>>>    because Eclipse creates valid class files regardless of compile
>>>>>    errors. The following package(s) import from the default
>>>>>    package [org.enquery.encryptedquery.responder.data.service.impl]
>>>>>    (biz.aQute.bnd:bnd-maven-plugin:4.0.0:bnd-process:default:process-classes)pom.xml/encryptedquery-responder-dataline
>>>>>    0Maven Build Participant Problem
>>>>>
>>>>>    The project was not built since its build path is incomplete.
>>>>>    Cannot find the class file for javax.persistence.EntityManager.
>>>>>    Fix the build path then try building this
>>>>>    projectencryptedquery-responder-dataUnknownJava Problem
>>>>>
>>>>>
>>>>
>>>> As the message suggests, this usually occurs when Eclipse has build 
>>>> errors for the project. Specifically in this case you seem to be 
>>>> building against a project which exposes the EntityManager interface 
>>>> somehow, but you don’t have the JPA API in your compile dependencies 
>>>> (normally these would come come in transitively from the project you 
>>>> depend on).
>>>>
>>>> I hope this helps,
>>>>
>>>> Tim
>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Alex soto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On May 18, 2018, at 5:23 AM, Tim Ward <tim.ward@paremus.com 
>>>>>> <mailto:tim.ward@paremus.com>> wrote:
>>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> The bundles you need are listed in the bndrun for the JPA version 
>>>>>> of the enRoute application, but as I think you’re using OpenJPA 
>>>>>> (rather than Hibernate) it may help to explain things in relation 
>>>>>> to the Transaction Control JPA integration test for OpenJPA. I’m 
>>>>>> sure that at least some of this will be stuff you already know, 
>>>>>> but I’m trying to make sure I give a compete explanation.
>>>>>>
>>>>>> This method defines some extra properties to add to the 
>>>>>> persistence unit. It references a couple of open bugs in OpenJPA 
>>>>>> which may or may not affect you. It also adds schema generation as 
>>>>>> OpenJPA does not support the standard properties from JPA 2.1 
>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L34
>>>>>>
>>>>>> This method defines the OpenJPA bundles and their immediate 
>>>>>> dependencies. 
>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L48
>>>>>>
>>>>>> You then need:
>>>>>>
>>>>>> • Aries JPA 2.7.0 - this provides the OSGi JPA Service 1.1 RI (1.1 
>>>>>> features are needed by the Aries Tx Control JPA resource provider 
>>>>>> to support XA)
>>>>>>
>>>>>> • Aries Tx Control Service - either XA or local depending on 
>>>>>> whether you need XA Transaction support. For example 
>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L365
>>>>>>
>>>>>> • Aries Tx Control JPA resource provider - either XA or local 
>>>>>> depending on your needs. Note that you can’t use the XA provider 
>>>>>> with the local service, but you can use the local provider with 
>>>>>> the XA service (although this doesn’t make a lot of sense to do). 
>>>>>> For example 
>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L377
>>>>>>
>>>>>> • A JDBC Service implementation supporting your database driver. 
>>>>>> H2 supports this natively (which is why it is used in many 
>>>>>> examples) but MariaDB does not. Therefore you will need to deploy 
>>>>>> PAX-JDBC’s support. See 
>>>>>> https://github.com/ops4j/org.ops4j.pax.jdbc/tree/master/pax-jdbc-mariadb
>>>>>>
>>>>>> You then have the option of either programmatically assembling 
>>>>>> your Resource Provider, or using configuration. Configuration is 
>>>>>> generally easier and is what I normally recommend. At that point 
>>>>>> you need to create a factory configuration for the relevant PID 
>>>>>> (it depends on whether you use the local or XA resource provider, 
>>>>>> see 
>>>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L175)
>>>>>>
>>>>>> The necessary configuration properties are:
>>>>>>
>>>>>> • url - the JDBC URL for your database
>>>>>> • osgi.jdbc.driver.class - the database driver class name, in your 
>>>>>> case org.mariadb.jdbc.Driver
>>>>>> • osgi.unit.name - the name of your persistence unit
>>>>>>
>>>>>> The result of this configuration will be a 
>>>>>> JPAEntityManagerProvider service registered in the service 
>>>>>> registry (using your EntityManagerFactoryBuilder and the MariaDB 
>>>>>> DataSourceFactory). You can then Inject that service into your 
>>>>>> code and combine it with the TransactionControl service to make a 
>>>>>> thread safe EntityManager that you can use in all your requests 
>>>>>> (just like the enRoute example does).
>>>>>>
>>>>>> I hope this helps,
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 17 May 2018, at 22:46, Alex Soto <alex.soto@envieta.com 
>>>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>>>
>>>>>>> Thanks Tim,
>>>>>>>
>>>>>>> I was using branch R7, changed to master, it builds now.
>>>>>>>
>>>>>>> Now I have updated my project to OSGi 7 with Transaction Control, 
>>>>>>> how do I deploy to Karaf?
>>>>>>> i.e., what bundles/features do I need?
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Alex soto
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On May 17, 2018, at 2:08 PM, Tim Ward <tim.ward@paremus.com 
>>>>>>>> <mailto:tim.ward@paremus.com>> wrote:
>>>>>>>>
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>> Bnd 4.0.0 was only released last Sunday, but this should have 
>>>>>>>> been changed yesterday in this commit 
>>>>>>>> https://github.com/osgi/osgi.enroute/commit/9f9857c3d317cd08a7aaf7327c1904676299f9ee to 
>>>>>>>> make sure enRoute kept building.
>>>>>>>>
>>>>>>>> EnRoute is automatically pushed to the sonatype OSGi nexus 
>>>>>>>> repository, so is it possible that you’re running offline, or 
>>>>>>>> firewalled from the repo? You should be able to force snapshot 
>>>>>>>> updates from the Maven command line.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 17 May 2018, at 18:26, Alex Soto <alex.soto@envieta.com 
>>>>>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>>>>>
>>>>>>>>> Allright,  I am trying to follow the EnRoute tutorial.
>>>>>>>>>
>>>>>>>>> I am getting this error:
>>>>>>>>>
>>>>>>>>> [ERROR] Plugin biz.aQute.bnd:bnd-maven-plugin:4.0.0-SNAPSHOT or 
>>>>>>>>> one of its dependencies could not be resolved: Could not find 
>>>>>>>>> artifact biz.aQute.bnd:bnd-maven-plugin:jar:4.0.0-SNAPSHOT in 
>>>>>>>>> Bnd 
>>>>>>>>> Snapshots (https://bndtools.ci.cloudbees.com/job/bnd.master/lastSuccessfulBuild/artifact/dist/bundles/) 
>>>>>>>>> -> [Help 1]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any idea (time frame) when this will move from SNAPSHOT 
>>>>>>>>> dependencies?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Alex soto
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On May 17, 2018, at 11:08 AM, Tim Ward <tim.ward@paremus.com 
>>>>>>>>>> <mailto:tim.ward@paremus.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> It is highly unlikely that you’ll hit the same issues. The 
>>>>>>>>>> transaction control resource provider uses the 
>>>>>>>>>> DataSourceFactory directly to create a DataSource (either 
>>>>>>>>>> progamatically using a factory service or via config admin) 
>>>>>>>>>> that enlists itself in the ongoing transaction. This means 
>>>>>>>>>> that the answer to your question is “with Transaction Control 
>>>>>>>>>> you don’t have to do that because it does it automatically”
>>>>>>>>>>
>>>>>>>>>> If you want to use XA transactions then the only requirement 
>>>>>>>>>> is that the DataSourceFactory can produce an XADataSource, 
>>>>>>>>>> otherwise it just uses the standard JDBC API to 
>>>>>>>>>> commit/rollback. If your DataSourceFactory doesn’t support XA 
>>>>>>>>>> then use the local resource provider implementation.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On 17 May 2018, at 15:17, Alex Soto <alex.soto@envieta.com 
>>>>>>>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I will take a look at these examples.
>>>>>>>>>>>
>>>>>>>>>>> However, I think that if I cannot get a MariaDB DataSource 
>>>>>>>>>>> that supports transactions, then it will still not work, right?
>>>>>>>>>>> If the examples use H2 database, I still may get different 
>>>>>>>>>>> results when I change to MariaDB, and I will find myself in 
>>>>>>>>>>> the same spot as of now.
>>>>>>>>>>>
>>>>>>>>>>> So, the question remains about what is the correct way how to 
>>>>>>>>>>> register a transaction aware MariaDB DataSource.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Alex soto
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On May 17, 2018, at 1:46 AM, Tim Ward <tim.ward@paremus.com 
>>>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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.soto@envieta.com 
>>>>>>>>>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I agree, it s very frustrating and time consuming. Almost 
>>>>>>>>>>>>> impossible to get it right.
>>>>>>>>>>>>> I may try the OSGi R7, but I am not sure of its adoption 
>>>>>>>>>>>>> level at this time, availability of bundles, examples, 
>>>>>>>>>>>>> support by Karaf, etc.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyway, back to my current stack.  I only see one 
>>>>>>>>>>>>> DataSource being registered:
>>>>>>>>>>>>>
>>>>>>>>>>>>> karaf@root()> service:list DataSource
>>>>>>>>>>>>> [javax.sql.DataSource]
>>>>>>>>>>>>> ----------------------
>>>>>>>>>>>>>  databaseName = responder
>>>>>>>>>>>>>  dataSourceName = responder
>>>>>>>>>>>>>  osgi.jdbc.driver.name = mariadb
>>>>>>>>>>>>>  osgi.jndi.service.name = responder
>>>>>>>>>>>>>  service.bundleid = 14
>>>>>>>>>>>>>  service.factoryPid = org.ops4j.datasource
>>>>>>>>>>>>> service.id <http://service.id/>= 194
>>>>>>>>>>>>>  service.pid = 
>>>>>>>>>>>>> org.ops4j.datasource.feb33f6d-dc46-4bc7-a417-ad6bdd5a6ee5
>>>>>>>>>>>>>  service.scope = singleton
>>>>>>>>>>>>>  url = jdbc:mariadb:XXXXXX
>>>>>>>>>>>>> Provided by :
>>>>>>>>>>>>>  OPS4J Pax JDBC Config (14)
>>>>>>>>>>>>> Used by:
>>>>>>>>>>>>>  Data (135)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure what to do with this.
>>>>>>>>>>>>> I specified the following in the configuration:
>>>>>>>>>>>>>
>>>>>>>>>>>>> pool=narayana
>>>>>>>>>>>>> xa=true
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Alex soto
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On May 16, 2018, at 4:12 PM, Tim Ward 
>>>>>>>>>>>>>> <tim.ward@paremus.com <mailto:tim.ward@paremus.com>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The structure of the JNDI name is defined by the JNDI 
>>>>>>>>>>>>>> service specification.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> osgi:service/<interface name>[/<filter>]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So in this case both of your services should be DataSource 
>>>>>>>>>>>>>> instances, but they should have different filters.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The important thing is to make sure you have an JTA 
>>>>>>>>>>>>>> enlisting DataSource registered as a service (this isn’t 
>>>>>>>>>>>>>> just your normal DataSource), then to build a filter which 
>>>>>>>>>>>>>> selects that. One option for this is to use the enlistment 
>>>>>>>>>>>>>> whiteboard from Aries (not well documented) 
>>>>>>>>>>>>>> https://github.com/apache/aries/tree/trunk/transaction/transaction-jdbc
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a non-trivial thing to do, which is why I keep 
>>>>>>>>>>>>>> mentioning Transaction Control which handles the 
>>>>>>>>>>>>>> enlistment reliably without the layers of services.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16 May 2018, at 21:57, Alex Soto <alex.soto@envieta.com 
>>>>>>>>>>>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you Tim.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any idea what the JNDI names would be?
>>>>>>>>>>>>>>> It is Pax-JDBC creating these JNDI names, so I have no idea.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From the Karaf console:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> karaf@root()> jndi:names
>>>>>>>>>>>>>>> JNDI Name              │ Class Name
>>>>>>>>>>>>>>> ───────────────────────┼───────────────────────────────────────────────
>>>>>>>>>>>>>>> osgi:service/responder │ org.mariadb.jdbc.MySQLDataSource
>>>>>>>>>>>>>>> osgi:service/jndi      │ 
>>>>>>>>>>>>>>> org.apache.karaf.jndi.internal.JndiServiceImpl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Alex soto
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On May 16, 2018, at 3:48 PM, Tim Ward 
>>>>>>>>>>>>>>>> <tim.ward@paremus.com <mailto:tim.ward@paremus.com>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Just looking quickly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You have the same JNDI name for both JTA and non JTA 
>>>>>>>>>>>>>>>> DataSources. This is clearly wrong as the DataSource 
>>>>>>>>>>>>>>>> cannot simultaneously be enlisted in the Transaction and 
>>>>>>>>>>>>>>>> not enlisted. The comments also indicate a 
>>>>>>>>>>>>>>>> misunderstanding of the purpose of the 
>>>>>>>>>>>>>>>> non-jta-datasource, which absolutely is used with JTA 
>>>>>>>>>>>>>>>> EntityManagers (for things like sequence allocation and 
>>>>>>>>>>>>>>>> out of band optimisations). You really do need to have 
>>>>>>>>>>>>>>>> both and they do need to behave differently.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> At a guess your DataSource is not enlisted with the 
>>>>>>>>>>>>>>>> transaction manager present in the system.  This usually 
>>>>>>>>>>>>>>>> happens by configuring a (otherwise invisible) 
>>>>>>>>>>>>>>>> DataSource wrapper There is nothing forcing you to make 
>>>>>>>>>>>>>>>> this happen (or checking that it does) hence your 
>>>>>>>>>>>>>>>> transactions would be broken. This is one of the several 
>>>>>>>>>>>>>>>> reasons I try to direct people to Transaction Control 
>>>>>>>>>>>>>>>> where the model actively pushes you toward transactions 
>>>>>>>>>>>>>>>> that actually work, rather than hiding all the magic 
>>>>>>>>>>>>>>>> behind an annotation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hopefully this gives you some clues as to what might be 
>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 16 May 2018, at 21:34, Jean-Baptiste Onofré 
>>>>>>>>>>>>>>>>> <jb@nanthrax.net <mailto:jb@nanthrax.net>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Are you sure about your code ? Flush looks weird to me 
>>>>>>>>>>>>>>>>> and it seems you don't use container managed transaction.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 16/05/2018 21:08, Alex Soto wrote:
>>>>>>>>>>>>>>>>>> Yes, same result.  I even tried with Narayana 
>>>>>>>>>>>>>>>>>> Transaction Manager, and same result.
>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>> Alex soto
>>>>>>>>>>>>>>>>>>> On May 16, 2018, at 2:56 PM, Jean-Baptiste Onofré 
>>>>>>>>>>>>>>>>>>> <jb@nanthrax.net 
>>>>>>>>>>>>>>>>>>> <mailto:jb@nanthrax.net><mailto:jb@nanthrax.net>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Same behavior with RequiresNew ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 16/05/2018 19:44, Alex Soto wrote:
>>>>>>>>>>>>>>>>>>>> With Karaf version 4.2.0, Rollback is not working 
>>>>>>>>>>>>>>>>>>>> with MariaDB and InnoDB tables.
>>>>>>>>>>>>>>>>>>>> I deployed these features (from Karaf’s enterprise 
>>>>>>>>>>>>>>>>>>>>  repository):
>>>>>>>>>>>>>>>>>>>> <feature>aries-blueprint</feature>
>>>>>>>>>>>>>>>>>>>> <feature>transaction</feature>
>>>>>>>>>>>>>>>>>>>> <feature>jndi</feature>
>>>>>>>>>>>>>>>>>>>> <feature>jdbc</feature>
>>>>>>>>>>>>>>>>>>>> <feature>jpa</feature>
>>>>>>>>>>>>>>>>>>>> <feature>pax-jdbc-mariadb</feature>
>>>>>>>>>>>>>>>>>>>>        <feature>pax-jdbc-config</feature>
>>>>>>>>>>>>>>>>>>>> <feature>pax-jdbc-pool-dbcp2</feature>
>>>>>>>>>>>>>>>>>>>> <feature>hibernate</feature>
>>>>>>>>>>>>>>>>>>>> My Data Source is configured in the file 
>>>>>>>>>>>>>>>>>>>> /org.ops4j.datasource-responder.cfg/
>>>>>>>>>>>>>>>>>>>>   osgi.jdbc.driver.name = mariadb
>>>>>>>>>>>>>>>>>>>>   dataSourceName=responder
>>>>>>>>>>>>>>>>>>>>   url
>>>>>>>>>>>>>>>>>>>>   = 
>>>>>>>>>>>>>>>>>>>> jdbc:mariadb://mariadb.local:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true&autocommit=false
>>>>>>>>>>>>>>>>>>>>   user=XXXX
>>>>>>>>>>>>>>>>>>>>   password=XXXX
>>>>>>>>>>>>>>>>>>>>   databaseName=responder
>>>>>>>>>>>>>>>>>>>>   #Pool Config
>>>>>>>>>>>>>>>>>>>>   pool=dbcp2
>>>>>>>>>>>>>>>>>>>>   xa=true
>>>>>>>>>>>>>>>>>>>> My persistence.xml:
>>>>>>>>>>>>>>>>>>>>   <persistence version="2.0" 
>>>>>>>>>>>>>>>>>>>> xmlns="http://java.sun.com/xml/ns/persistence"
>>>>>>>>>>>>>>>>>>>>        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>>>>>>>>>>>>>>>        xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>>>>>>>>>>>>>>>>>>>> http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
>>>>>>>>>>>>>>>>>>>>            <persistence-unit 
>>>>>>>>>>>>>>>>>>>> name="responderPersistenUnit" transaction-type="JTA">
>>>>>>>>>>>>>>>>>>>>                <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
>>>>>>>>>>>>>>>>>>>>            <!-- Only used when transaction-type=JTA -->
>>>>>>>>>>>>>>>>>>>>                <jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)</jta-data-source>
>>>>>>>>>>>>>>>>>>>>            <!-- Only used when 
>>>>>>>>>>>>>>>>>>>> transaction-type=RESOURCE_LOCAL -->
>>>>>>>>>>>>>>>>>>>>                <non-jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)</non-jta-data-source>
>>>>>>>>>>>>>>>>>>>>            <properties>
>>>>>>>>>>>>>>>>>>>>                    <property 
>>>>>>>>>>>>>>>>>>>> name=“hibernate.dialect" 
>>>>>>>>>>>>>>>>>>>> value="org.hibernate.dialect.MySQL5Dialect" />
>>>>>>>>>>>>>>>>>>>>                <property name="hibernate.show_sql" 
>>>>>>>>>>>>>>>>>>>> value="true" />
>>>>>>>>>>>>>>>>>>>>                <property name="hibernate.format_sql" 
>>>>>>>>>>>>>>>>>>>> value="true" />
>>>>>>>>>>>>>>>>>>>>                <property 
>>>>>>>>>>>>>>>>>>>> name="hibernate.hbm2ddl.auto" value="none"/>
>>>>>>>>>>>>>>>>>>>>            </properties>
>>>>>>>>>>>>>>>>>>>>        </persistence-unit>
>>>>>>>>>>>>>>>>>>>>   </persistence>
>>>>>>>>>>>>>>>>>>>> My blueprint.xml:
>>>>>>>>>>>>>>>>>>>>   <blueprint 
>>>>>>>>>>>>>>>>>>>> xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>>>>>>>>>>>>>>>>>>   xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0"
>>>>>>>>>>>>>>>>>>>>   xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0"
>>>>>>>>>>>>>>>>>>>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>>>>>>>>>>>>>>>   xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
>>>>>>>>>>>>>>>>>>>> https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>>>>>>>>>>>>>>>>>>>   <jpa:enable />
>>>>>>>>>>>>>>>>>>>>   <tx:enable />
>>>>>>>>>>>>>>>>>>>>   <bean id="userService" 
>>>>>>>>>>>>>>>>>>>> class="org.data.impl.UserServiceImpl" />
>>>>>>>>>>>>>>>>>>>>   <service ref="userService" 
>>>>>>>>>>>>>>>>>>>> interface="org.data.UserService" />
>>>>>>>>>>>>>>>>>>>>   </blueprint>
>>>>>>>>>>>>>>>>>>>> For testing I throw exception in my DAO:
>>>>>>>>>>>>>>>>>>>> @Transactional(REQUIRED)
>>>>>>>>>>>>>>>>>>>> public void addUser(User user) {
>>>>>>>>>>>>>>>>>>>> em.persist(user);
>>>>>>>>>>>>>>>>>>>> em.flush();
>>>>>>>>>>>>>>>>>>>> throw new RuntimeException("On Purpose");
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>> I expect the record not to be in the table due to 
>>>>>>>>>>>>>>>>>>>> rollback of the transaction, but it still shows up 
>>>>>>>>>>>>>>>>>>>> in my database table.
>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>> Alex soto
> 

Mime
View raw message