Seems to be working ok now with extremely minor changes. https://github.com/sahlex/declarative-poc/pull/1 <https://github.com/sahlex/declarative-poc/pull/1>
Best Regards Tim > On 15 Sep 2017, at 08:36, alexander.sah...@brodos.de wrote: > > Tim, > > please find the project here: > https://github.com/sahlex/declarative-poc > <https://github.com/sahlex/declarative-poc> > > Best, Alexander. > > > > Note that this work should be done as part of a new transaction control > service implementation (there’s some common code which should help to speed > up implementing it), not as changes to the current implementation, which is > undergoing stabilisation as the Reference Implementation of the OSGi > Transaction control service. > > Also this update still won’t avoid the need for the JPA resource provider to > have a custom plugin for transaction integration. The whole point of a > managed resource is that it integrates with the Transaction Control service > that gets passed to it, not by integrating with a third party service which > may, or may not, be involved. > > Alexander - is there any chance of seeing the proof of concept code? It seems > as though it’s pretty close to working with the existing bundles. > > Regards, > > Tim > > >> On 14 Sep 2017, at 12:42, <alexander.sah...@brodos.de >> <mailto:alexander.sah...@brodos.de>> <alexander.sah...@brodos.de >> <mailto:alexander.sah...@brodos.de>> wrote: >> >> I'll give it a try. Maybe with a little guidance of you guys. First of all >> I'll try to inject a JTA TransactionManager into tx-control instead of the >> internal one. If that is working, I'll let you know. >> >> >> >> >>> On 14 Sep 2017, at 10:46, Guillaume Nodet <gno...@apache.org >>> <mailto:gno...@apache.org>> wrote: >>> >>> >>> >>> 2017-09-14 11:40 GMT+02:00 Timothy Ward <tim.w...@paremus.com >>> <mailto:tim.w...@paremus.com>>: >>> Hi Alexander, >>> >>> As has been discussed on the Aries lists before, I have no problem with >>> someone creating a separate implementation of the Transaction Control >>> service which leverages the OSGi JTA Service Specification. The reason that >>> the current implementation doesn’t do this is twofold: >>> >>> By embedding a transaction manager the current Tx Control implementation >>> can avoid the javax.transaction split package from the JVM. This makes the >>> implementation easier to use and deploy because the user doesn’t need to >>> mess around with the boot class path, or worry about what JTA version is >>> available >>> By embedding a transaction manager the current Tx control implementation >>> can rely on specific behaviours of the transaction manager that it uses. >>> This means that the Tx control implementation can support the last resource >>> gambit and XA recovery. >>> Fwiw, as I already indicated, the pax-transx project provides a layer >>> solving those problems, in addition of providing additional features and >>> pluggability. >>> >>> Would you be interested to incorporate it in Tx Control ? >> >> This is not something that I have the time to do, but another implementation >> of a transaction control service with a pluggable transaction manager would >> be a great addition. >> >>> >>> Guillaume >>> >>> >>> If this is a proof of concept project then are you able to share it >>> somewhere (e.g. GitHub)? I’d like to help you get to the bottom of the NPE >>> that you’re seeing as I don’t think it should be possible for that to be >>> happening! >>> >>> Finally - yes the Aries user list is the best place to talk about this, but >>> I don’t want to move the conversation myself as I don’t know whether you’re >>> registered for that list, and don’t want you to miss my replies. >>> >>> Regards, >>> >>> Tim >>> >>> >>>> On 14 Sep 2017, at 07:53, <alexander.sah...@brodos.de >>>> <mailto:alexander.sah...@brodos.de>> <alexander.sah...@brodos.de >>>> <mailto:alexander.sah...@brodos.de>> wrote: >>>> >>>> Hi Tim. >>>> >>>> I'm using the 2.6.1 version of aries jpa support already. Normal >>>> transaction control with blueprint and @Transactional annotation was >>>> working fine. >>>> >>>> To have better control over startup dependencies and cope with >>>> disappearing and appearing services during runtime we invest some time in >>>> a Proof-Of-Concept for switching over to declarative services (DS). >>>> Everything works fine so far - even restful services for DS with cxf-dosgi >>>> works fine. Last bit to get it working is transaction management. With DS, >>>> the @Transactional annotation is not working anymore due to the lack of >>>> interceptors with DS. >>>> >>>> What do you think of the idea that tx-control should pick up a JTS >>>> Transaction manager from the service registry instead of creating an own >>>> one with new operator which is in fact tightly coupled. To implement loose >>>> coupling here we should add a factory that may be configurable in the >>>> factory config file. >>>> >>>> BTW, should we switch the discussion to aries group still? >>>> >>>> Best, Alexander. >>>> >>>> >>>> >>>> Hi Alexander, >>>> >>>> That looks like it should be fine - what version of Aries JPA are you >>>> using? There were some fixes made to Aries JPA in 2.4.0 to add support for >>>> JPA 2.1 configuration properties which are needed by the transaction >>>> control implementation, and I think that there were then more fixes in >>>> 2.5.0 which are needed to get XA working with Hibernate. 2.6.1 is the >>>> latest release version. >>>> >>>> Regards, >>>> >>>> Tim >>>> >>>> >>>>> On 13 Sep 2017, at 15:42, alexander.sah...@brodos.de >>>>> <mailto:alexander.sah...@brodos.de> wrote: >>>>> >>>>> Thanks Tim for the update. >>>>> >>>>> I tried the approach with providing a factory config in >>>>> karaf.dir/etc/org.apache.aries.tx.control.jpa.xa.cfg with config as: >>>>> osgi.unit.name <http://osgi.unit.name/>=DSContext2 >>>>> osgi.jdbc.driver.class=org.h2.Driver >>>>> url=jdbc:h2:mem:article >>>>> user=sa >>>>> password= >>>>> >>>>> whilst having a mininmal persistence.xml like: >>>>> <persistence-unit name="DSContext" > >>>>> <properties> >>>>> <property name="hibernate.dialect" >>>>> value="org.hibernate.dialect.H2Dialect" /> >>>>> </properties> >>>>> </persistence-unit> >>>>> >>>>> (without the dialect I see another exception; Access to >>>>> DialectResolutionInfo cannot be null when 'hibernate.dialect' not set). >>>>> >>>>> Now I get further in the process (transaction enlistment works) but when >>>>> actually accessing the database, the entity manager throws a NPE while >>>>> trying to open the connection. In >>>>> JPAEntityManagerProviderFactoryImpl.EnlistingDataSource.enlistedConnection() >>>>> while calling supplier.call, the supplier.delegate member is null: >>>>> >>>>> org.osgi.service.transaction.control.TransactionException: There was a >>>>> problem getting hold of a database connection >>>>> at >>>>> org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.enlistedConnection(JPAEntityManagerProviderFactoryImpl.java:241) >>>>> ~[?:?] >>>>> at >>>>> org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.getConnection(JPAEntityManagerProviderFactoryImpl.java:193) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:35) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:99) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:129) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:47) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:146) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:172) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:148) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1940) ~[?:?] >>>>> at >>>>> org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1909) ~[?:?] >>>>> at >>>>> org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1887) ~[?:?] >>>>> at org.hibernate.loader.Loader.doQuery(Loader.java:932) ~[?:?] >>>>> at >>>>> org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:349) >>>>> ~[?:?] >>>>> at org.hibernate.loader.Loader.doList(Loader.java:2615) ~[?:?] >>>>> at org.hibernate.loader.Loader.doList(Loader.java:2598) ~[?:?] >>>>> at >>>>> org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2430) ~[?:?] >>>>> at org.hibernate.loader.Loader.list(Loader.java:2425) ~[?:?] >>>>> at >>>>> org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:335) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.internal.SessionImpl.listCustomQuery(SessionImpl.java:2153) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.internal.AbstractSharedSessionContract.list(AbstractSharedSessionContract.java:991) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.query.internal.NativeQueryImpl.doList(NativeQueryImpl.java:147) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1410) >>>>> ~[?:?] >>>>> at >>>>> org.hibernate.query.internal.AbstractProducedQuery.getSingleResult(AbstractProducedQuery.java:1459) >>>>> ~[?:?] >>>>> at >>>>> com.brodos.ds.persistence.h2.TestRepositoryImpl.lambda$checkHealth$0(TestRepositoryImpl.java:47) >>>>> ~[?:?] >>>>> at >>>>> org.apache.aries.tx.control.service.common.impl.AbstractTransactionControlImpl$TransactionBuilderImpl.doWork(AbstractTransactionControlImpl.java:161) >>>>> [241:tx-control-service-xa:0.0.3] >>>>> at >>>>> org.apache.aries.tx.control.service.common.impl.AbstractTransactionControlImpl$TransactionBuilderImpl.required(AbstractTransactionControlImpl.java:84) >>>>> [241:tx >>>>> <https://maps.google.com/?q=84)+%5B241:tx&entry=gmail&source=g>-control-service-xa:0.0.3] >>>>> at >>>>> org.apache.aries.tx.control.service.common.impl.AbstractTransactionControlImpl.required(AbstractTransactionControlImpl.java:263) >>>>> [241:tx-control-service-xa:0.0.3] >>>>> at >>>>> com.brodos.ds.persistence.h2.TestRepositoryImpl.checkHealth(TestRepositoryImpl.java:44) >>>>> [160:com.brodos.example.ds.DSContext-infrastructure:1.0.0.SNAPSHOT] >>>>> at >>>>> com.brodos.ds.service.impl.MainHealthCheck.checkHealth(MainHealthCheck.java:29) >>>>> [209:com.brodos.example.ds.DSContext-service:1.0.0.SNAPSHOT] >>>>> at >>>>> com.brodos.ds.application.boundary.impl.HealthCheckImpl.checkHealth(HealthCheckImpl.java:37) >>>>> [212:com.brodos.example.ds.DSContext-application:1.0.0.SNAPSHOT] >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> ~[?:?] >>>>> at >>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> ~[?:?] >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> ~[?:?] >>>>> at java.lang.reflect.Method.invoke(Method.java:497) ~[?:?] >>>>> at >>>>> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180) >>>>> [84:org.apache.cxf.cxf-core:3.1.12] >>>>> at >>>>> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) >>>>> [84:org.apache.cxf.cxf-core:3.1.12] >>>>> at >>>>> org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:189) >>>>> [85:org.apache.cxf.cxf-rt-frontend-jaxrs:3.1.12] >>>>> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99) >>>>> [85:org.apache.cxf.cxf-rt-frontend-jaxrs:3.1.12] >>>>> at >>>>> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) >>>>> [84:org.apache.cxf.cxf-core:3.1.12] >>>>> at >>>>> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96) >>>>> [84:org.apache.cxf.cxf-core:3.1.12] >>>>> at >>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) >>>>> [84:org.apache.cxf.cxf-core:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) >>>>> [84:org.apache.cxf.cxf-core:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:263) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at >>>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:223) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>> [69:javax.servlet-api:3.1.0] >>>>> at >>>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274) >>>>> [92:org.apache.cxf.cxf-rt-transports-http:3.1.12] >>>>> at >>>>> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) >>>>> [128:org.eclipse.jetty.servlet:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) >>>>> [128:org.eclipse.jetty.servlet:9.3.14.v20161028] >>>>> at >>>>> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) >>>>> [150:org.ops4j.pax.web.pax-web-jetty:6.0.6] >>>>> at >>>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) >>>>> [125:org.eclipse.jetty.security:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) >>>>> [150:org.ops4j.pax.web.pax-web-jetty:6.0.6] >>>>> at >>>>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) >>>>> [128:org.eclipse.jetty.servlet:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) >>>>> [150:org.ops4j.pax.web.pax-web-jetty:6.0.6] >>>>> at >>>>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at org.eclipse.jetty.server.Server.handle(Server.java:534) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) >>>>> [127:org.eclipse.jetty.server:9.3.14.v20161028] >>>>> at org.eclipse.jetty.io >>>>> <http://org.eclipse.jetty.io/>.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) >>>>> [119:org.eclipse.jetty.io >>>>> <http://org.eclipse.jetty.io/>:9.3.14.v20161028] >>>>> at org.eclipse.jetty.io >>>>> <http://org.eclipse.jetty.io/>.FillInterest.fillable(FillInterest.java:95) >>>>> [119:org.eclipse.jetty.io >>>>> <http://org.eclipse.jetty.io/>:9.3.14.v20161028] >>>>> at org.eclipse.jetty.io >>>>> <http://org.eclipse.jetty.io/>.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) >>>>> [119:org.eclipse.jetty.io >>>>> <http://org.eclipse.jetty.io/>:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) >>>>> [130:org.eclipse.jetty.util:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) >>>>> [130:org.eclipse.jetty.util:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) >>>>> [130:org.eclipse.jetty.util:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) >>>>> [130:org.eclipse.jetty.util:9.3.14.v20161028] >>>>> at >>>>> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) >>>>> [130:org.eclipse.jetty.util:9.3.14.v20161028] >>>>> at java.lang.Thread.run(Thread.java:745) [?:?] >>>>> Caused by: java.lang.NullPointerException >>>>> at >>>>> org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.lambda$getConnection$4(JPAEntityManagerProviderFactoryImpl.java:193) >>>>> ~[?:?] >>>>> at >>>>> org.apache.aries.tx.control.jpa.xa.impl.JPAEntityManagerProviderFactoryImpl$EnlistingDataSource.enlistedConnection(JPAEntityManagerProviderFactoryImpl.java:230) >>>>> ~[?:?] >>>>> ... 78 more >>>>> >>>>> Best, Alexander >>>>> >>>>> >>>>> >>>>> Hi Alexander, >>>>> >>>>> So what you’re doing is passing a fully configured EntityManagerFactory >>>>> to the resource provider factory. If you create the provider this way >>>>> then you are responsible for setting up all of the EntityManagerFactory’s >>>>> configuration, including how it’s going to integrate with transaction >>>>> control. For local transactions there is nothing to integrate with , but >>>>> in the general case this is actually quite hard to do, and I would advise >>>>> not trying to do it. >>>>> >>>>> As you can see the EntityManagerFactory version of the provider factory >>>>> <https://github.com/apache/aries/blob/ed8dbc79758766081203056cff27eb0bcbd7efb3/tx-control/tx-control-providers/jpa/tx-control-provider-jpa-xa/src/main/java/org/apache/aries/tx/control/jpa/xa/impl/JPAEntityManagerProviderFactoryImpl.java#L122> >>>>> does quite a bit less setup on your behalf than the configuration-driven >>>>> version does >>>>> <https://github.com/apache/aries/blob/ed8dbc79758766081203056cff27eb0bcbd7efb3/tx-control/tx-control-providers/jpa/tx-control-provider-jpa-xa/src/main/java/org/apache/aries/tx/control/jpa/xa/impl/XAJPAEMFLocator.java#L72>. >>>>> If you were to >>>>> provide a factory configuration for the >>>>> “org.apache.aries.tx.control.jpa.xa” pid containing “osgi.unit.name >>>>> <http://osgi.unit.name/>=<your persistence unit’s name>” and any >>>>> necessary datasource configuration (i.e. that’s not coming from the >>>>> persistence xml) then you could inject the JPAEntityManagerProvider >>>>> directly as a service. >>>>> >>>>> More documentation about configuration-driven resources for Aries >>>>> Tx-Control is available at >>>>> http://aries.apache.org/modules/tx-control/xaJPA.html#creating-a-resource-using-a-factory-configuration >>>>> >>>>> <http://aries.apache.org/modules/tx-control/xaJPA.html#creating-a-resource-using-a-factory-configuration> >>>>> >>>>> Another thing that probably could be done would be to look at dynamically >>>>> installing the plugin when using the EntityManagerFactoryBuilder version >>>>> of the factory method. This, however, would need a patch to Aries >>>>> Transaction Control, and would still not make your existing code work. >>>>> >>>>> Regards, >>>>> >>>>> Tim >>>>> >>>>> >>>>>> On 13 Sep 2017, at 10:59, <alexander.sah...@brodos.de >>>>>> <mailto:alexander.sah...@brodos.de>> <alexander.sah...@brodos.de >>>>>> <mailto:alexander.sah...@brodos.de>> wrote: >>>>>> >>>>>> Hi Tim, >>>>>> >>>>>> I use a JPAEntityManagerProviderFactory (providerFactory) which I inject >>>>>> as a service reference into my repository class. >>>>>> Furthermore, I inject a EntityManagerFactory (emf) into the repository >>>>>> class as well as the TransactionControl (txControl). >>>>>> >>>>>> The provider Factory is created by pax-jdbc (I use hibernate). >>>>>> >>>>>> This provider factory is then used to get the Entity manager like this: >>>>>> >>>>>> EntityManager em = providerFactory.getProviderFor(emf, >>>>>> null).getResource(txControl); >>>>>> >>>>>> It fails giving an exception telling that transaction cannot be joined, >>>>>> because it's not open. >>>>>> >>>>>> The wrapping call is like this: >>>>>> txControl.build() >>>>>> .required( >>>>>> () -> repo.store(article)); >>>>>> >>>>>> Best, Alexander. >>>>>> >>>>>> >>>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> Do you have a code example of how you’re obtaining and using the >>>>>> EntityManager? There should be no usage of the OSGiJtaPlatform from the >>>>>> tx-control XA JPA resource provider, which means that there’s either a >>>>>> bug in the resource provider, or something is misconfigured. If you are >>>>>> a member of the Aries user mailing list then that would be a better >>>>>> place to continue this discussion. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Tim >>>>>> >>>>>>> On 13 Sep 2017, at 09:21, Guillaume Nodet <gno...@apache.org >>>>>>> <mailto:gno...@apache.org>> wrote: >>>>>>> >>>>>>> Fwiw, you should ask on the Aries mailing list, where tx-control is >>>>>>> developed. >>>>>>> >>>>>>> I've recently worked on a new project called pax-transx which provides >>>>>>> an abstraction layer on top of transaction managers so that some >>>>>>> features can be accessed in a common way. I think this should be used >>>>>>> in tx-control instead of wrapping the tm again and not being flexible. >>>>>>> Right now, tx-control uses its own instance of transaction manager and >>>>>>> there's no way around afaik, so you can't use the karaf transaction >>>>>>> feature if you want to use it. >>>>>>> Anyway, I'd gladly support you if you go to the aries mailing list to >>>>>>> raise this point ! >>>>>>> >>>>>>> 2017-09-13 9:52 GMT+02:00 <alexander.sah...@brodos.de >>>>>>> <mailto:alexander.sah...@brodos.de>>: >>>>>>> Hello. >>>>>>> >>>>>>> I'm trying to get tx-control with XA transactions running (local is >>>>>>> working). >>>>>>> I found that tx-control opens a JTA transaction using >>>>>>> RecoveryWorkAroundTransactionManager (derived from geronimo's >>>>>>> TransactionManager Implementation) explicitly instead of using the >>>>>>> registered TransactionManager (aries in my case for karaf 4.0.9). When >>>>>>> hibernate EntityManager implementation tries to join the transaction it >>>>>>> fails because it uses the TransactionManager provided by >>>>>>> OsgiJtaPlatform (from hibernate-osgi) which is of course the one >>>>>>> registered in osgi ecosystem. >>>>>>> >>>>>>> I think that the tx-control implementation has to use the >>>>>>> TransactionManager registered with OSGi. >>>>>>> >>>>>>> Has anyone got that thing ever running? >>>>>>> >>>>>>> Best Alexander. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------ >>>>>>> Guillaume Nodet >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >> >
