karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <timothyjw...@apache.org>
Subject Re: [PROPOSAL] New pax project 'transx'
Date Tue, 20 Jun 2017 14:37:14 GMT
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
officer of the OSGi Alliance, so I can’t speak on their behalf. Finally, I wasn’t part
of any previous discussion between OPS4j and the OSGi Alliance about accepting implementations
from OPS4j, so I do not know what any specific sticking points might have been.

I do know that in order for an “external” community to contribute reference implementations
to the OSGi Alliance (which seems to be what we’re talking about here) there are rules about
acceptable Open Source licences, levels of community diversity, legal IP governance and guarantees
of originality for the code. There are probably other important requirements that I am not
aware of. I know that Apache and Eclipse are examples of acceptable external communities which
are regularly used to provide reference implementations, and that OPS4j is currently not on
that list.

There may be very little for OPS4j to do to become another such community, or there may be
some thornier problems that would need to be solved before that could be the case. If you
want anything more specific I strongly recommend contacting the OSGi Alliance, either through
a board member or the CTO. See https://www.osgi.org/about-us/board-officers/ for contact details.

Best Regards,

Tim


On 20 Jun 2017, at 12:12, Achim Nierbeck <bcanhome@googlemail.com<mailto:bcanhome@googlemail.com>>
wrote:

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<mailto: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<mailto:gnodet@apache.org>>
wrote:

2017-06-16 11:16 GMT+02:00 Richard Nicholson <puppy_wants_a_hug@me.com<mailto: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<mailto: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<mailto: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