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 contribution-wise then I'm sure you'd see a flow of work > in the other direction too. especially the "If OPS4j are able to get to a compatible place contribution-wise" what in your view is missing for the OPS4j community to be regarded a compatible place? regards, Achim 2017-06-20 12:53 GMT+02:00 Timothy Ward <[email protected]>: > 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 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 contribution-wise then I'm sure you'd see a flow of work > in the other direction too. > > As for Aries Tx Control - a Narayana based XA implementation would be a > great addition, as would JMS support. > > Wrapping the Geronimo transaction manager is deliberate for three reasons: > > * the javax.transaction package is toxic due to its split package in the > JRE. Hiding all of the JTA code allows the impl to work without system > packages being declared when launching the OSGi framework. > > * by being Geronimo specific the implementation can offer last participant > support > > * by being Geronimo specific the implementation can support XA recovery > > This model gives a great level of functionality in an easy to access way > for users, and I would be keen to keep this option. A pluggable model is > possible, but would need to be done carefully to ensure that scopes could > cope with external parties "messing with" the transaction. It would also > lose the benefits described above, although neither of these things mean > that it would not be worth adding as an alternative implementation. > > Finally - I am not sure why tx Control would have a dependency on pax jdbc > (other than as a source of DataSourceFactory services)? This sounds like it > would make the Aries project harder to configure and deploy, and I can't > immediately see what additional benefits it would provide. Can you clarify? > > Regards, > > Tim > > Sent from my iPhone > > > On 20 Jun 2017, at 11:00, Guillaume Nodet <[email protected]> wrote: > > > > 2017-06-16 11:16 GMT+02:00 Richard Nicholson <[email protected]>: > > > >> > >> 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. > >> > > > > Yeah, I'm a bit skeptic about the relationship between the OPS4j > community > > and the OSGi Alliance work. It seems to always go in the same > direction... > > i.e. the guys working at OPS4j should help working on the project defined > > by the guys working at the OSGi Alliance. > > > > That being said, the work in Aries is about defining a new programming > > model for transactions. That's something I'm not really interested in at > > this point. In addition, my initial goal is to have support for JMS + > > Narayana and both aspects are not covered. In particular, it does create > > and wrap the geronimo TransactionManager instead of re-using an external > > one (even the one defined in Aries Transaction for example). > > > > In theory, things should be layered. For example, pax-jdbc provides a > way > > to expose DataSourceFactory objects in the OSGi registry. Imho, > pooling > > should be done at this level, as specified in the DataSourceFactory > > interface. So pooling inside aries-tx-control is irrelevant. > > > > This project is even at a lower level and I plan to integrate it below > > pax-jdbc for the jdbc part. > > > > That said, I may have a look at aries-tx-control and see if I can replace > > some of the code there to leverage pax-jdbc and pax-transx more to help > > avoiding confusion and fragmentation. > > > > > >> > >>> On 15 Jun 2017, at 13:55, Toni Menzel <[email protected]> wrote: > >>> > >>> 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) appears in your Service Registry. Maybe > >> it's > >>> just me not following bridge provider-projects like Aries too closely. > >>> Anything that makes setup simpler and offers a wider range of options > >> is > >>> highly welcome. (particularly in the OPS4J community, or how Bndtools > >>> people say "P A X" ;) > >>> - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the > >>> Transx a bit alien. just an idea. > >>> > >>> Thanks for your heads up, JB about karaf-boot. Was wondering what > >> happened > >>> to it. > >>> > >>> Toni > >>> > >>> > >>> On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck < > [email protected] > >>> > >>> wrote: > >>> > >>>> 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é <[email protected]>: > >>>> > >>>>> +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 threads. > >>>>> > >>>>> Regards > >>>>> JB > >>>>> > >>>>> > >>>>>> On 06/15/2017 09:57 AM, Guillaume Nodet wrote: > >>>>>> > >>>>>> 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 pax-jdbc-pool-narayana when using the Narayana > >> transaction > >>>>>> manager. > >>>>>> > >>>>>> However, there's absolutely no support for JMS. > >>>>>> > >>>>>> So what I've been doing is to reuse the geronimo JCA connector, make > >> it > >>>>>> independent on Geronimo TM and add support for Narayana, use a clone > >> of > >>>>>> the > >>>>>> old tranql adapter for JDBC and rewrite a new JMS 2.0 compatible > >> adapter > >>>>>> for JMS. > >>>>>> > >>>>>> It's not in a usable state yet, but I wanted to give an heads-up. > >>>>>> My plan is to make the pooling almost transparent in OSGi, and reuse > >> it > >>>>>> instead of the connection pooling I added to Karaf a few weeks ago > >> which > >>>>>> does not support XA or recovery: > >>>>>> https://github.com/apache/karaf/tree/master/jms/pool > >>>>>> and maybe to plug it into pax-jdbc to replace pax-jdbc-pool-aries > and > >>>>>> pax-jdbc-pool-narayana. > >>>>>> > >>>>>> The source code is currently available at: > >>>>>> https://github.com/gnodet/org.ops4j.pax.transx > >>>>>> > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> > >>>>> -- > >>>>> Jean-Baptiste Onofré > >>>>> [email protected] > >>>>> http://blog.nanthrax.net > >>>>> Talend - http://www.talend.com > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Apache Member > >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC > >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > >> Committer & > >>>> Project Lead > >>>> blog <http://notizblog.nierbeck.de/> > >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > >>>> > >>>> Software Architect / Project Manager / Scrum Master > >>>> > >> > >> > > > > > > -- > > ------------------------ > > Guillaume Nodet > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
