You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2014/01/30 15:03:00 UTC
Cleanups in JMS transport for CXF 3
Hi all,
I would like to do some cleanups in the jms transport for CXF 3.
- Remove SingleConnectionFactory references
We currently do transparent wrapping with a SingleConnectionFactory. I
would like to remove this. There are good pooling solutions available
now. So the SingleConnectionFactory is not neccessary anymore. The
impact for users is that they have to use pooling to achieve a good
performance
- Remove PlattformTransactionManager references
This is a spring proprietary feature that can now be replaced by full XA
solutions like the aries transaction manager. So to make sure we still
provide transaction support we need an example with XA transactions and
perhaps a test
- Remove spring jms
CXF is quite independent from spring now. The only big dependency is
through the jms transport. It needs spring jms and so pulls in a lot of
spring jars.
I would like to replace spring jms with some code that is standalone. I
checked the code and found most of the spring jms dependencies are
around setting up the DefaultMessageListenerContainer and to a smaller
degree JMSTemplate. I am not yet sure how much effort it would be. I
will experiment a bit and in any case provide the changes in a branch
for review.
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Cleanups in JMS transport for CXF 3
Posted by Daniel Kulp <dk...@apache.org>.
I know the Camel folks introduced a new simple JMS component that uses the pure JMS API’s. I was kind of hoping they would extract some of it out into a nice library or something we could steal.. er… use, but they didn’t. In any case, that code may be something to look at as well.
In anycase, let me know if there is anything you’d like some help with. :-)
Dan
On Jan 30, 2014, at 9:03 AM, Christian Schneider <ch...@die-schneider.net> wrote:
> Hi all,
>
> I would like to do some cleanups in the jms transport for CXF 3.
>
> - Remove SingleConnectionFactory references
> We currently do transparent wrapping with a SingleConnectionFactory. I would like to remove this. There are good pooling solutions available now. So the SingleConnectionFactory is not neccessary anymore. The impact for users is that they have to use pooling to achieve a good performance
>
> - Remove PlattformTransactionManager references
> This is a spring proprietary feature that can now be replaced by full XA solutions like the aries transaction manager. So to make sure we still provide transaction support we need an example with XA transactions and perhaps a test
>
> - Remove spring jms
> CXF is quite independent from spring now. The only big dependency is through the jms transport. It needs spring jms and so pulls in a lot of spring jars.
>
> I would like to replace spring jms with some code that is standalone. I checked the code and found most of the spring jms dependencies are around setting up the DefaultMessageListenerContainer and to a smaller degree JMSTemplate. I am not yet sure how much effort it would be. I will experiment a bit and in any case provide the changes in a branch for review.
>
> Best regards
>
> Christian
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Cleanups in JMS transport for CXF 3
Posted by Alessio Soldano <as...@redhat.com>.
Hi,
On 30/01/14 15:03, Christian Schneider wrote:
> - Remove spring jms
> CXF is quite independent from spring now. The only big dependency is
> through the jms transport. It needs spring jms and so pulls in a lot
> of spring jars.
>
> I would like to replace spring jms with some code that is standalone.
> I checked the code and found most of the spring jms dependencies are
> around setting up the DefaultMessageListenerContainer and to a smaller
> degree JMSTemplate. I am not yet sure how much effort it would be. I
> will experiment a bit and in any case provide the changes in a branch
> for review.
>
+1
I'd love to see the jms transport decoupled from spring.
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
RE: Cleanups in JMS transport for CXF 3
Posted by Andrei Shakirin <as...@talend.com>.
+1 for all three points.
Regarding replacing the spring, I am a bit concerned regarding the efforts, I thought it is not trivial thing to do.
Let me know if you need any help, especially in transport or system tests topics.
Regards,
Andrei.
> -----Original Message-----
> From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of
> Christian Schneider
> Sent: Donnerstag, 30. Januar 2014 15:03
> To: CXF Dev List
> Subject: Cleanups in JMS transport for CXF 3
>
> Hi all,
>
> I would like to do some cleanups in the jms transport for CXF 3.
>
> - Remove SingleConnectionFactory references We currently do transparent
> wrapping with a SingleConnectionFactory. I would like to remove this. There
> are good pooling solutions available now. So the SingleConnectionFactory is
> not neccessary anymore. The impact for users is that they have to use
> pooling to achieve a good performance
>
> - Remove PlattformTransactionManager references This is a spring
> proprietary feature that can now be replaced by full XA solutions like the
> aries transaction manager. So to make sure we still provide transaction
> support we need an example with XA transactions and perhaps a test
>
> - Remove spring jms
> CXF is quite independent from spring now. The only big dependency is
> through the jms transport. It needs spring jms and so pulls in a lot of spring
> jars.
>
> I would like to replace spring jms with some code that is standalone. I
> checked the code and found most of the spring jms dependencies are
> around setting up the DefaultMessageListenerContainer and to a smaller
> degree JMSTemplate. I am not yet sure how much effort it would be. I will
> experiment a bit and in any case provide the changes in a branch for review.
>
> Best regards
>
> Christian
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com