I got it working while creating the features myself.
Hi,
did you see my message?
Is the feature still in progress or is it just me that did not find it?
Am Mo., 22. Juli 2019 um 13:03 Uhr schrieb Markus Rathgeb :
>
> Hi JB,
>
> can you point me to the feature repositories I need to add to Karaf
> 4.2.6 to use OSGi R7 transaction
Hi JB,
can you point me to the feature repositories I need to add to Karaf
4.2.6 to use OSGi R7 transaction control and JPA?
Am Di., 5. Feb. 2019 um 16:53 Uhr schrieb Jean-Baptiste Onofré
:
>
> I'm volunteer to add the features repository in aries-tx-control. That
> would be helpful
to:tim.w...@paremus.com>> wrote:
>>
>> Hi,
>>
>> The model is the way it is quite deliberately, and there are several usage
>> issues with doing what you’re suggesting:
>>
>> It is unclear whether the EntityManager service is a scoped resource (and
he EntityManager service is a scoped resource (and
> therefore managed) or not to external users
> It is unclear which Transaction Control service implementation the scoped
> resource is attached to (the getResource(txControl) call creates an important
> link). If you use the wron
Hi,
The model is the way it is quite deliberately, and there are several usage
issues with doing what you’re suggesting:
It is unclear whether the EntityManager service is a scoped resource (and
therefore managed) or not to external users
It is unclear which Transaction Control service
rces (which is what
> the ResourceProvider gives you) is the Transaction Control Specification. In
> this case your question is covered by Section 147.2.5 Multi Threading
> <https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html#d0e127038>.
>
>
&
Tim: thank you for the clarification.
Best regards,
Alex soto
> On Feb 6, 2019, at 4:40 PM, Tim Ward wrote:
>
> The relevant specification for learning about scoped resources (which is what
> the ResourceProvider gives you) is the Transaction Control Specification. In
>
The relevant specification for learning about scoped resources (which is what
the ResourceProvider gives you) is the Transaction Control Specification. In
this case your question is covered by Section 147.2.5 Multi Threading
<https://osgi.org/specification/osgi.cmpn/7.
Actually, I took a stab at this again since I had some spare time now. I am
almost done. It looks promising.
The only question I have is about the entity manager. In the examples, I see
an entity manager is obtained in the activate method, and used for the rest of
the life of the component:
Thanks for the feedback Tim.
I created the following Jira to add a example about tx in general and
tx-control in particular:
https://issues.apache.org/jira/browse/KARAF-6140
By hte way, before the end of this week, I will send the first action of
the "kloud initiative". Especially, I will send
Hi Alex,
yes it is possible to use tx-control with Karaf, we have been using it on
v4.0.5 in our production system for about 18 months with no issues. One of
the main reasons we use tx-control is that is it 'backed' by a standard.
Rightly or wrongly we also didn't have confidence in Aries JPA
t;>>>> I am pretty sure you can use it.
>>>>>>
>>>>>> There is an example in enroute:
>>>>>> https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
>>>>>>
>>>>>> If you
>>>> There is an example in enroute:
>>>>> https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
>>>>>
>>>>> If you use the same bundles it should work.
>>>>> We can create a karaf featur
examples/microservice/rest-app-jpa
>>>>
>>>> If you use the same bundles it should work.
>>>> We can create a karaf feature in the aries-tx-control repo for it to
>>>> make it easier to install.
>>>>
>>>> Christian
>>>
app-jpa
>>>
>>> If you use the same bundles it should work.
>>> We can create a karaf feature in the aries-tx-control repo for it to
>>> make it easier to install.
>>>
>>> Christian
>>>
>>> Am Di., 5. Feb. 2019 um 16:34
t; If you use the same bundles it should work.
>> We can create a karaf feature in the aries-tx-control repo for it to
>> make it easier to install.
>>
>> Christian
>>
>> Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
>> mailto:alex.s...@envieta.com>
to:alex.s...@envieta.com>>:
>
> Hi,
>
> Is it possible to use Transaction Control Service Specification with
> Karaf?
>
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
>
>
> Any good example or tutoria
.
Christian
Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto :
> Hi,
>
> Is it possible to use Transaction Control Service Specification with Karaf?
>
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
>
>
> Any good example or tutorial?
>
:
> Hi,
>
> Is it possible to use Transaction Control Service Specification with Karaf?
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
>
>
> Any good example or tutorial?
>
> (I am currently using Aries JPA Template, but I
Hi,
Is it possible to use Transaction Control Service Specification with Karaf?
https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
<https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html>
Any good example or tutorial?
(I am cur
: Re: Transaction Control
Hi Scott,
Those are the two bundles that you need. At a guess Karaf is unhappy because
the Aries bundles substitutably export the API packages that they need
(including config admin) for ease of deployment. When installing bundles Karaf
sometimes attempts some
Hi Scott,
Those are the two bundles that you need. At a guess Karaf is unhappy because
the Aries bundles substitutably export the API packages that they need
(including config admin) for ease of deployment. When installing bundles Karaf
sometimes attempts some interesting package rewiring
I've been trying to integrate this into my app. I just pulled down the latest
(0.0.3) jars from Maven Central. As far as I can tell, the two bundles I need
are
tx-control-service-local
tx-control-provider-jdbc-local
I can drop the first one into my deploy directory and it tells me it needs 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 com
> On 14 Sep 2017, at 16:01, Guillaume Nodet <gno...@apache.org> wrote:
>
>
>
> 2017-09-14 14:17 GMT+02:00 Timothy Ward <tim.w...@paremus.com
> <mailto:tim.w...@paremus.com>>:
> Note that this work should be done as part of a new transaction control
2017-09-14 14:17 GMT+02:00 Timothy Ward <tim.w...@paremus.com>:
> 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 implem
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
2017-09-14 11:40 GMT+02:00 Timothy Ward <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 re
e, 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
2017-09-14 11:40 GMT+02:00 Timothy Ward <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
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
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
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
integrate with transaction control. For local transactions there is
nothing to integrate with , but in the general case this is act
ually
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/a
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/b
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
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
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
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
40 matches
Mail list logo
