Re: OSGi related PoC and Karaf

[Christian Schneider]

There is a big overlap between the jax-rs whiteboard and the jax-rs
providers for RSA.
We also discussed about this on the aries list.

In practice you can use any of the alternatives with different drawbacks.

Christian

2017-06-15 20:39 GMT+02:00 Milen Dyankov :

> Hmm ok I'm confused. I was thinking about the JAX-RS Services whiteboard
> spec that is now being implemented in Apache Aries. I'm aware of the the
> remote services spec but not sure how it relates to jax-rs connector .
>
>
>
> 15 cze 2017 20:11 "Scott Lewis"  napisał(a):
>
> On 6/15/2017 1:24 AM, Milen Dyankov wrote:
>
> > Thanks Scott,
> >
> > I was looking into that some time ago but AFAIK it comes in R7. Not sure
> if
> > thete is anything released at this point that would work with R6.
> >
>
> Were you saying 'there'?   The OSGi remote services and RSA specs have been
> quite stable since R5 (chap 100 and 122 in compendium).
>
> The Jax-RS distribution provider impls that I'm aware of are ECF's [1].
>  It supports Jersey's or CXF's Jax-RS impls.
>
> I will attempt to work on a reworking of your POC remote service metadata
> for a pull request, after the upcoming ECF release (June 28 I think).
>
> Scott
>
> [1] https://github.com/ECF/JaxRSProviders
>
>
> So for
> > now I just decided to go with what I know works. But if you have
> practical
> > experience with this spec, pull request would be more than welcome.
> >
> > Best,
> > Milen
> >
> >
> >
> >
> > 14 cze 2017 18:59 "Scott Lewis"  napisał(a):
> >
> > On 6/14/2017 4:46 AM, Milen Dyankov wrote:
> >
> > Hi Karaf developers,
> >>
> >> I'd like to ask you to have a look at something I've been working on.
> It's
> >> a PoC called Eccentric Modularity (EM) and it's available here
> >> https://github.com/azzazzel/EM
> >>
> >> FWIW:I think your example would be improved by using OSGi remote
> > services specs for the remote service metadata (e.g. provide/require
> > capability, standardized remote service properties, etc) rather than the
> > jax-rs connector specifically.   It would also then allow for supporting
> > osgi remote service dynamics, service versioning, rs discovery, etc.
> >
> > Scott
> >
> >
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: OSGi related PoC and Karaf

[Milen Dyankov]

Hmm ok I'm confused. I was thinking about the JAX-RS Services whiteboard
spec that is now being implemented in Apache Aries. I'm aware of the the
remote services spec but not sure how it relates to jax-rs connector .



15 cze 2017 20:11 "Scott Lewis"  napisał(a):

On 6/15/2017 1:24 AM, Milen Dyankov wrote:

> Thanks Scott,
>
> I was looking into that some time ago but AFAIK it comes in R7. Not sure if
> thete is anything released at this point that would work with R6.
>

Were you saying 'there'?   The OSGi remote services and RSA specs have been
quite stable since R5 (chap 100 and 122 in compendium).

The Jax-RS distribution provider impls that I'm aware of are ECF's [1].
 It supports Jersey's or CXF's Jax-RS impls.

I will attempt to work on a reworking of your POC remote service metadata
for a pull request, after the upcoming ECF release (June 28 I think).

Scott

[1] https://github.com/ECF/JaxRSProviders


So for
> now I just decided to go with what I know works. But if you have practical
> experience with this spec, pull request would be more than welcome.
>
> Best,
> Milen
>
>
>
>
> 14 cze 2017 18:59 "Scott Lewis"  napisał(a):
>
> On 6/14/2017 4:46 AM, Milen Dyankov wrote:
>
> Hi Karaf developers,
>>
>> I'd like to ask you to have a look at something I've been working on. It's
>> a PoC called Eccentric Modularity (EM) and it's available here
>> https://github.com/azzazzel/EM
>>
>> FWIW:I think your example would be improved by using OSGi remote
> services specs for the remote service metadata (e.g. provide/require
> capability, standardized remote service properties, etc) rather than the
> jax-rs connector specifically.   It would also then allow for supporting
> osgi remote service dynamics, service versioning, rs discovery, etc.
>
> Scott
>
>

Re: OSGi related PoC and Karaf

[Scott Lewis]

On 6/15/2017 1:24 AM, Milen Dyankov wrote:

Thanks Scott,

I was looking into that some time ago but AFAIK it comes in R7. Not sure if
thete is anything released at this point that would work with R6.


Were you saying 'there'?   The OSGi remote services and RSA specs have 
been quite stable since R5 (chap 100 and 122 in compendium).


The Jax-RS distribution provider impls that I'm aware of are ECF's 
[1].   It supports Jersey's or CXF's Jax-RS impls.


I will attempt to work on a reworking of your POC remote service 
metadata for a pull request, after the upcoming ECF release (June 28 I 
think).


Scott

[1] https://github.com/ECF/JaxRSProviders


So for
now I just decided to go with what I know works. But if you have practical
experience with this spec, pull request would be more than welcome.

Best,
Milen




14 cze 2017 18:59 "Scott Lewis"  napisał(a):

On 6/14/2017 4:46 AM, Milen Dyankov wrote:


Hi Karaf developers,

I'd like to ask you to have a look at something I've been working on. It's
a PoC called Eccentric Modularity (EM) and it's available here
https://github.com/azzazzel/EM


FWIW:I think your example would be improved by using OSGi remote
services specs for the remote service metadata (e.g. provide/require
capability, standardized remote service properties, etc) rather than the
jax-rs connector specifically.   It would also then allow for supporting
osgi remote service dynamics, service versioning, rs discovery, etc.

Scott

Re: [PROPOSAL] New pax project 'transx'

[Toni Menzel]

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 
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é :
>
> > +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é
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> Software Architect / Project Manager / Scrum Master
>

Re: [PROPOSAL] New pax project 'transx'

[Achim Nierbeck]

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 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é
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

[GitHub] karaf pull request #320: [KARAF-5208] Improve feature:install error message

[jludvice]

GitHub user jludvice opened a pull request:

https://github.com/apache/karaf/pull/320

[KARAF-5208] Improve feature:install error message

R: @jbonofre

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jludvice/karaf KARAF-5208

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/karaf/pull/320.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #320


commit 1e17733ef5c6d7119ab0a1e88b9607c7d0fcee34
Author: Josef Ludvicek 
Date:   2017-06-15T11:51:56Z

[KARAF-5208] Improve feature:install error message




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: OSGi related PoC and Karaf

[Christian Schneider]

2017-06-15 10:38 GMT+02:00 Milen Dyankov :

> I'm actually thinking of taking your chat demo and reimplementing it with
> EM just to see if it will make it easier to understand for non-OSGi folks
> and perhaps better demonstrate the purpose of EM.
>

That would be great. Looking forsward to see how it looks like.

Christian


>
> The examples I have now are very simple and from the perspective of large
> OSGI projects do not seem to add any value. That's why I was hoping to get
> some ideas/help to move towards more "real life" examples.
>
> Best,
> Milen
>
> 14 cze 2017 22:19 "Christian Schneider" 
> napisał(a):
>
> > Actually I hope we can make OSGi so easy to use that you do not need to
> be
> > an expert to start using it.
> > With a coarse grained modular approach where you just need to enumerate
> > some technologies to combine I think we can achieve a lot in this regard.
> >
> > Still I have doubts that we can make it as simple as spring boot. Spring
> > boot emphasizes easy setup at the cost of higher coupling. The problem is
> > that people only realize this when they bought into the technology as the
> > coupling only becomes a problem once your project grows.
> >
> > So I think we need to not try to be as simple as spring boot and instead
> > sell the better modularity combined with reasonable simplicity.
> >
> > Christian
> >
> > 2017-06-14 21:52 GMT+02:00 Milen Dyankov :
> >
> > > Thanks for your comments Christian,
> > >
> > > I understand this goes too far into making things simple to be useful
> for
> > > OSGi veterans. And that's OK. I don't aim to make OSGi or BND better
> for
> > > those who master them, but to lower the entry barrier. I think
> > (especially
> > > with JPMS promise for simple modularity around the corner) we need to
> > show
> > > to developers the benefits in the simplest possible way. I already
> > > presented this concept to a couple of conferences. I haven't mentioned
> > OSGi
> > > not even once during the talks - just presented it as new concept for
> > > dependency management. From my experience the moment you mention OSGi
> to
> > an
> > > average 20+ years old java developer you'll see his ironic smile and
> then
> > > his back. After this talk some people who never thought of modular apps
> > > before were quite interested. Some of them mentioned they never
> > understand
> > > the point of modularity this way (for them it was simply putting code
> is
> > > separate jar files).
> > >
> > > The reason I though of Karaf is because I know JB and other have been
> > > discussing KarafBoot and I think it has a similar goal (but different
> > > approach). I alway wanted a ModularityBoot kind of thing that will be
> > > simple and at the same time flexible as far as choosing a runtime is
> > > concerned. So I thought I'll share this with you here in case we can
> > > somehow combine the ideas.
> > >
> > > As for the parent POM, I'm aware of that possibility but I didn't used
> on
> > > purpose. In fact you'll see the demo.* projects don't actually have a
> > > parent, they are just aggregated in the demo project. The reason is, I
> > use
> > > this in my talk and I want to point out those are completely free to
> use
> > > any corporate parent pom they need to.
> > >
> > > Best,
> > > Milen
> > >
> > >
> > > On Wed, Jun 14, 2017 at 8:59 PM, Christian Schneider <
> > > ch...@die-schneider.net> wrote:
> > >
> > > > Hi Milen,
> > > >
> > > > the concept is interesting when you are outside of OSGi but in that
> > case
> > > I
> > > > doubt people will use OSGi requirements and tools even if it woud
> make
> > > > sense.
> > > >
> > > > When inside OSGi I do not see a big benefit compared to using plain
> > > > bnd-maven-plugin, bnd-index-plugin and bnd-export-plugin like I use
> in
> > > > https://github.com/cschneider/osgi-chat .
> > > > Merging all this functionality into one plugin is not a good idea
> > imho. I
> > > > prefer the unix like idea of small single purpose projects.
> > > >
> > > > As a general improvement for the bnd toolset I could imagine that the
> > > > bnd-export-maven-plugin uses the current pom as a basis for an OBR
> > index
> > > by
> > > > default. So if you just need one packaging you could omit the
> separate
> > > > index pom that I use right now. Another possible improvement would be
> > > that
> > > > it can be put in the parent and auto exports all bndrun files it
> finds.
> > > >
> > > > I agree that a bndrun file is a bit difficult to write from scratch.
> I
> > > > wonder if we could provide parts of it from bundles that form kind of
> > > > profiles. These could then contribute to the system package exports
> or
> > > > other settings for specific technologies by using special Manifest
> > > headers.
> > > > Such information could then be used by bnd as well as karaf to setup
> > the
> > > > runtime correctly.
> > > >
> > > > One thing you could improve in your code is to define
> > > > the em-maven-extension in the parent. So the ind

[GitHub] karaf pull request #319: [KARAF-5206] modified karaf and karaf.bat scripts t...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/karaf/pull/319


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: OSGi related PoC and Karaf

[Milen Dyankov]

I'm actually thinking of taking your chat demo and reimplementing it with
EM just to see if it will make it easier to understand for non-OSGi folks
and perhaps better demonstrate the purpose of EM.

The examples I have now are very simple and from the perspective of large
OSGI projects do not seem to add any value. That's why I was hoping to get
some ideas/help to move towards more "real life" examples.

Best,
Milen

14 cze 2017 22:19 "Christian Schneider" 
napisał(a):

> Actually I hope we can make OSGi so easy to use that you do not need to be
> an expert to start using it.
> With a coarse grained modular approach where you just need to enumerate
> some technologies to combine I think we can achieve a lot in this regard.
>
> Still I have doubts that we can make it as simple as spring boot. Spring
> boot emphasizes easy setup at the cost of higher coupling. The problem is
> that people only realize this when they bought into the technology as the
> coupling only becomes a problem once your project grows.
>
> So I think we need to not try to be as simple as spring boot and instead
> sell the better modularity combined with reasonable simplicity.
>
> Christian
>
> 2017-06-14 21:52 GMT+02:00 Milen Dyankov :
>
> > Thanks for your comments Christian,
> >
> > I understand this goes too far into making things simple to be useful for
> > OSGi veterans. And that's OK. I don't aim to make OSGi or BND better for
> > those who master them, but to lower the entry barrier. I think
> (especially
> > with JPMS promise for simple modularity around the corner) we need to
> show
> > to developers the benefits in the simplest possible way. I already
> > presented this concept to a couple of conferences. I haven't mentioned
> OSGi
> > not even once during the talks - just presented it as new concept for
> > dependency management. From my experience the moment you mention OSGi to
> an
> > average 20+ years old java developer you'll see his ironic smile and then
> > his back. After this talk some people who never thought of modular apps
> > before were quite interested. Some of them mentioned they never
> understand
> > the point of modularity this way (for them it was simply putting code is
> > separate jar files).
> >
> > The reason I though of Karaf is because I know JB and other have been
> > discussing KarafBoot and I think it has a similar goal (but different
> > approach). I alway wanted a ModularityBoot kind of thing that will be
> > simple and at the same time flexible as far as choosing a runtime is
> > concerned. So I thought I'll share this with you here in case we can
> > somehow combine the ideas.
> >
> > As for the parent POM, I'm aware of that possibility but I didn't used on
> > purpose. In fact you'll see the demo.* projects don't actually have a
> > parent, they are just aggregated in the demo project. The reason is, I
> use
> > this in my talk and I want to point out those are completely free to use
> > any corporate parent pom they need to.
> >
> > Best,
> > Milen
> >
> >
> > On Wed, Jun 14, 2017 at 8:59 PM, Christian Schneider <
> > ch...@die-schneider.net> wrote:
> >
> > > Hi Milen,
> > >
> > > the concept is interesting when you are outside of OSGi but in that
> case
> > I
> > > doubt people will use OSGi requirements and tools even if it woud make
> > > sense.
> > >
> > > When inside OSGi I do not see a big benefit compared to using plain
> > > bnd-maven-plugin, bnd-index-plugin and bnd-export-plugin like I use in
> > > https://github.com/cschneider/osgi-chat .
> > > Merging all this functionality into one plugin is not a good idea
> imho. I
> > > prefer the unix like idea of small single purpose projects.
> > >
> > > As a general improvement for the bnd toolset I could imagine that the
> > > bnd-export-maven-plugin uses the current pom as a basis for an OBR
> index
> > by
> > > default. So if you just need one packaging you could omit the separate
> > > index pom that I use right now. Another possible improvement would be
> > that
> > > it can be put in the parent and auto exports all bndrun files it finds.
> > >
> > > I agree that a bndrun file is a bit difficult to write from scratch. I
> > > wonder if we could provide parts of it from bundles that form kind of
> > > profiles. These could then contribute to the system package exports or
> > > other settings for specific technologies by using special Manifest
> > headers.
> > > Such information could then be used by bnd as well as karaf to setup
> the
> > > runtime correctly.
> > >
> > > One thing you could improve in your code is to define
> > > the em-maven-extension in the parent. So the individual projects do not
> > > need it.
> > > I did this for the bnd-maven-plugin so each project just needs a
> bnd.bnd
> > > file if it wants to override defaults.
> > >
> > > Christian
> > >
> > > 2017-06-14 13:46 GMT+02:00 Milen Dyankov :
> > >
> > > > Hi Karaf developers,
> > > >
> > > > I'd like to ask you to have a look at something I've been working on.
>

[GitHub] karaf pull request #319: [KARAF-5206] modified karaf and karaf.bat scripts t...

[valdar]

GitHub user valdar opened a pull request:

https://github.com/apache/karaf/pull/319

[KARAF-5206] modified karaf and karaf.bat scripts to check pid and pr…

…ocess name upon cheking for already running instances

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/valdar/karaf KARAF-5206

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/karaf/pull/319.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #319


commit c5941764ee5db731e24ad3949a14db5f60537d82
Author: Andrea Tarocchi 
Date:   2017-06-15T08:12:01Z

[KARAF-5206] modified karaf and karaf.bat scripts to check pid and process 
name upon cheking for already running instances




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: OSGi related PoC and Karaf

[Milen Dyankov]

Thanks Scott,

I was looking into that some time ago but AFAIK it comes in R7. Not sure if
thete is anything released at this point that would work with R6. So for
now I just decided to go with what I know works. But if you have practical
experience with this spec, pull request would be more than welcome.

Best,
Milen




14 cze 2017 18:59 "Scott Lewis"  napisał(a):

On 6/14/2017 4:46 AM, Milen Dyankov wrote:

> Hi Karaf developers,
>
> I'd like to ask you to have a look at something I've been working on. It's
> a PoC called Eccentric Modularity (EM) and it's available here
> https://github.com/azzazzel/EM
>

FWIW:I think your example would be improved by using OSGi remote
services specs for the remote service metadata (e.g. provide/require
capability, standardized remote service properties, etc) rather than the
jax-rs connector specifically.   It would also then allow for supporting
osgi remote service dynamics, service versioning, rs discovery, etc.

Scott

Re: [PROPOSAL] New pax project 'transx'

[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 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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[PROPOSAL] New pax project 'transx'

[Guillaume Nodet]

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,
-- 

Guillaume Nodet