Refactor JMS transport second step (patch included)
-----------------------------------------------------
Key: CXF-1783
URL: https://issues.apache.org/jira/browse/CXF-1783
Project: CXF
Issue Type: Improvement
Components: Transports
Affects Versions: 2.1.2
Reporter: Christian Schneider
Fix For: 2.1.3
I have refactored several parts of the JMS Transport to make it easier to
understand and to help preparing for a move to the spring jms classes.
The refactoring should not change the functionality.
SessionFactory and PooledSession:
The sessionfactory had two different caches and a lot of redundant code. I have
now only one cache left that starts send only. A consumer is then added when
the first client needs it. The lines of code of SessionFactory are reduced from
450 to 300.
Functionality of JMSProviderHub is splitted between SessionFactory and JMSUtils
The connect method now does not need a callback anymore. So the interface
JMSOnConnectCallback is deleted.
JMSOutputStream:
Extracted the class from JMSDestination and JMSConduit. They both use the same
JMSOutputStream now. A new interface JMSExchangeSender calls back into
JMSConduit or JMSDestination.
JMSListenerThread and JMSExecutor:
Extracted JMSListenerThread from JMSDestination. So the complete JMS listen
functionality is factored out. This means it will be easier to port to Spring
MessageListenerContainer. JMSListener does not use the Session pool anymore as
it does not need pooling anyway.
JMSConduit:
Made the program flow easier again and documented where the flow of operation
is not easy to understand. 420 lines => 290 lines
JMSDestination:
Same as with JMSConduit. 550 lines => 420 lines
Tests:
All tests work
- Cut most of PooledSessionTest as it does not apply anymore. Have not written
a new test yet. But I think it is mostly implicitly tested by other tests
- AbstractJMSTests replaced setInMessage with setOutMessage. I think this was
wrong before. Please review
- JMSDestinationTest added a second message send as I had an issue with a
closed session after first send because of an error in the SessionFactory. This
is to avoid regression
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
