aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [PROPOSAL] New pax project 'transx'
Date Tue, 20 Jun 2017 11:12:53 GMT
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 <timothyjward@apache.org>:

> 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 <gnodet@apache.org> wrote:
> >
> > 2017-06-16 11:16 GMT+02:00 Richard Nicholson <puppy_wants_a_hug@me.com>:
> >
> >>
> >> 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 <toni.menzel@rebaze.com> 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 <
> bcanhome@googlemail.com
> >>>
> >>> 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é <jb@nanthrax.net>:
> >>>>
> >>>>> +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é
> >>>>> jbonofre@apache.org
> >>>>> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message