Hi Sergey,
this does not really work as JmsTemplate and also MessageListener are
used independently of the way you configure the jms endpoint.
Sadly spring does not offer JmsTemplate and MessageListener in a
packaging that is independent of the rest of spring. Still these classes
really simplify
jms handling so I think they are worth the dependency.
Greetings
Christian
Am 03.08.2010 12:20, schrieb Sergey Beryozkin:
Hi Willem
On Tue, Aug 3, 2010 at 11:15 AM, Willem Jiang<[email protected]>wrote:
Hi Sergey,
CXF JMS transport is base on Spring JMS template now, so even you remove
the spring dependency of JMSConfiguration. You can't let the
cxf-jms-transport work without Spring :(.
What's your plan about it ?
My understanding that Spring JMS template is not strictly required for the
JMS transport to function ? In other words, a WSDL-first case with the (old)
JMS configuration specified in the service/port should just work ?
cheers, SErgey
Willem
Sergey Beryozkin wrote:
Hi
I'm looking at the issue to do with the JMS transport strongly depending
on
Spring.
As it happens, JMSConfiguration implements (Spring) InitializingBean for
the
only purpose of verifying that
a connectionFactory has been set.
This causes problems when doing non-Spring CXF deployments.
Generally, we should really try to keep the Spring related code in .spring
subpackages as it will make it simpler for CXF be integrated with other
similar frameworks or deployed in containers providing the optional Spring
support only.
I'm planning just remove this dependency from the JMSConfiguration so that
the JMS transport can be deployed without Spring with 2.2.10.
This is really the main property but if it's not been set for some reason
in
the Spring case then it will be caught anyway. That said, I'll add another
check
in JMSConfiguration.getOrCreateWrappedConnectionFactory (which by the way
attempts to get the connectionFactory from JNDI if it's currently null) to
ensure it's been initialized.
cheers, Sergey
--
----
http://www.liquid-reality.de
