Re: [PROPOSAL] New pax project 'transx'

Hi Achim, I am certain that that this is a conversation that has been had before, and that it would be better for any revisit of this discussion to be held between OPS4j and the Alliance rather than on the Karaf/Aries dev lists. I am also not an OSGi board representative, nor am I corporate

Re: [PROPOSAL] New pax project 'transx'

Hi Tim, could you please elaborate on this a bit more? On the other hand to maintain the openness of its standards the OSGi > Alliance must have a strict IP policy, one that prevents it from consuming > arbitrary code or IP from external sources. If OPS4j are able to get to a > compatible place

Re: [PROPOSAL] New pax project 'transx'

Hi Christian The Transaction Control API has no OSGi framework dependency, so a Java SE mode of operation would be possible (just like Aries blueprint no osgi). Possibly something worth exploring? Tim Sent from my iPhone > On 20 Jun 2017, at 11:35, Christian Schneider

Re: [PROPOSAL] New pax project 'transx'

Hi Guillaume, The OSGi Alliance is an open organisation, and a number of OPS4j developers are already members via their companies. There is absolutely nothing preventing them from getting involved with the Alliance, nor preventing any non-members from joining. On the other hand to maintain

Re: [PROPOSAL] New pax project 'transx'

Aries transaction control has a lot of good parts. Unfortunately though it is an all or nothing solution. It works well if you directly depend on Aries transaction control in your user code. Unfortunately this makes the code OSGi only. So this is not an option for many projects like CXF or

Re: [PROPOSAL] New pax project 'transx'

2017-06-16 11:16 GMT+02:00 Richard Nicholson : > > Doesn’t this directly clash with OSGi Alliance Transaction Control > Specification work going on in Aries? > > If so, wouldn’t it make more sense for this community to input into that > work rather than cause needless

Re: [PROPOSAL] New pax project 'transx'

The Transaction Control project in Aries does have a pretty complete overlap with what’s being proposed here. There are already resource providers for JPA and JDBC which provide connection pooling, resource local transactions and XA transactions. It would be great to get some input into a JMS

Re: [PROPOSAL] New pax project 'transx'

+1 Great about forking tranql - finally ;) regards Grzegorz 2017-06-16 11:16 GMT+02:00 Richard Nicholson : > > Doesn’t this directly clash with OSGi Alliance Transaction Control > Specification work going on in Aries? > > If so, wouldn’t it make more sense for this

Re: [PROPOSAL] New pax project 'transx'

Doesn’t this directly clash with OSGi Alliance Transaction Control Specification work going on in Aries? If so, wouldn’t it make more sense for this community to input into that work rather than cause needless confusion / fragmentation? Just a thought. > On 15 Jun 2017, at 13:55, Toni

Re: [PROPOSAL] New pax project 'transx'

Sounds interesting! Two comments: - i find the whole space of "pooling resources" a not confusing and hard to find out what you actually really need. So, say once you know you want takaricp, which other bridges and matching configs do you need so that the DataSource proxy (for JDBC)

Re: [PROPOSAL] New pax project 'transx'

Hi Guillaume, sounds like a good idea to me, and the pax space like the perfect eco system :) regards, Achim 2017-06-15 10:20 GMT+02:00 Jean-Baptiste Onofré : > +1 > > It sounds like a good idea and definitely a good candidate for PAX. > > By the way, on my side, I did good

Re: [PROPOSAL] New pax project 'transx'

+1 It sounds like a good idea and definitely a good candidate for PAX. By the way, on my side, I did good progress on: - karaf sample & new dev guide - some new updates on karaf-boot - ServiceMix APIMan for API/Service Discovery, Management, Gateway But I will send an update in separate

[PROPOSAL] New pax project 'transx'

I began to work on a small project which aims at providing support for pooled XA-enabled connections for JDBC and JMS. For JDBC, the problem was already solved in pax-jdbc by using either pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction manager, and by using