[
https://issues.apache.org/jira/browse/CXF-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637668#action_12637668
]
Christian Schneider commented on CXF-1832:
------------------------------------------
Hi Freeman,
currently the ClientImpl calls chain.doIntercept(message) it then expects an
in message when the chain returns. So I have to make sure it returns one. I do
not know what needs to be done to make this truly asynchronous.
For the transport code it would be nice if a Conduit would consist of an out
Channel and an in Channel. Where the out channel simply sends messages out and
the in channel would simply feed the received message into a chain. The
correlation should be done in the CXF core code. The problem is that I do not
know what needs to be done to implement such an architecture and I do not know
either if the other developers would agree with my viewpoint. Perhaps we should
start a discussion about this.
Greetings
Christian
> Third step of Refactoring JMS Transport
> ---------------------------------------
>
> Key: CXF-1832
> URL: https://issues.apache.org/jira/browse/CXF-1832
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Christian Schneider
> Fix For: 2.1.3
>
> Attachments: client-applicationContext.xml
>
>
> I have completed the third step in the refactoring. This I have done the
> following things:
> - Rewritten JMSConfiguration. Removed JmsTemplate and MesssageListener. Added
> their config settings instead. I did this because I want the config to be
> reuseable over several services
> - Made JMSConduit asynchronous. Instead of doing a receive on the JmsTemplate
> I open one Spring DefaultMessageListenerContainer that waits for all replies.
> The sending threads then waits for the listener to receive the message. the
> communication happens over a synchronized map
> - Rewrite of JMSDestination to use JmsTemplate and DefaultMessageLIstener
> - First start of transactions. Support sessionTransacted and
> transactionManager
> - Removed JMSListenerThread, SessionFactory and PooledSession
> - Added documentation to most classes and methods
> Some things are not finished:
> - QoS settings do not work completely. I have implemented Qos that can be
> statically set using the config. Do we need different QoS settings per
> message?
> - QoS on the server is not thread safe. JmsTemplate does not support setting
> QoS when sending the message. You have to set things like priority in the
> properties. I think this should be improved in JmsTemplate
> - Several settings will probably not yet work
> - I have added TODO tasks to the code where I think some more work has to be
> done
> - Transactions will probably not yet work as we need to throw an exception
> when something happens. I guess when an exception occurs in the server code
> of the service we will not throw it up till the listener. Any ideas how to
> achieve this?
> I will try to do my first commit with my new account for this one
> Please feel free to give some feedback about the changes
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
