[
https://issues.apache.org/jira/browse/CXF-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated CXF-1806:
-------------------------------------
Attachment: CXF-1806.patch
In this patch I completely replaced the JMS API calls with JMSTemplate in
JMSConduit. I also introduced a new JMSConfiguration class. This directly
contains a JMSTemplate and a JMSListeningContainer. The JMSConduit does not
know of the old configuration anymore and instead uses only the new config
class.
The JMSConfiguration is built from the old configs like AddressType. So it is
fully backwards compatible. A new class JMSOldConfigholder is used to build the
new config.
The tests work and I also tested the code with my own project. Still I am not
so sure if the new config should directly contain a JMSTemplate. The idea was
to be able to simply get a template injected in the spring config but I am not
so sure if this is a good idea.
Another issue with the code in the patch is that it does not cache Consumers
and temporary queues for the reply. I am not sure how important this is. See
below for my idea how to better solve the possible performance problem.
Please review the patch and give me some feedback about the design. The patch
should only be committed if we get positive feedback from one or the other
senior developer.
I am thinking about a larger redesign of the JMSConduit. Instead of a blocking
receive I would like to use a Listener to receive the replies asynchronously
with one ore more threads. For temporary queues this would mean that we only
need one queue instead of one queue per pooled session. I could need some
feedback if this is a good idea and how to correlate the asynchronously
received reply to the right request.
> Use Spring JMSTemplate in JMSConduit instead of direct JMS
> ----------------------------------------------------------
>
> Key: CXF-1806
> URL: https://issues.apache.org/jira/browse/CXF-1806
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Fix For: 2.1.3
>
> Attachments: CXF-1806.patch
>
>
> Using the Spring JMSTemplate has many advantages compared to directly using
> the JMS API. For example cxf services can participate in Transactions.
> The goal for this issue is to replace JMS API in JMSConduit with JMSTemplate
> calls. Additionally the JMSConduit should be made more dependency injection
> friendly. It should not retrieve configuration from the Spring config.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
