karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ward <tim.w...@paremus.com>
Subject Re: MariaDB/JPA Transaction rollback not working
Date Sat, 19 May 2018 05:32:04 GMT
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.jencks@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.soto@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é <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>>
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>>
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