Using the Spring JmsTemplate and Messagelistener really improved the
jms transport code. I was able to remove much infrastructure code where
we simply reinvented the wheel. So I think it was a good idea to use it
versus doing it all from scratch.
There is one problem with these spring classes though. They bring in a
big part of the spring stack into each module that uses them. I think it
is the same as with Spring JdbcTemplate.
So people who do not want to use spring dependency injection still are
forced to have the code for it in their apps. While this is only some
jars that do not hurt that much I still understand that this is not exactly
what people would like to have.
So I think the best solution is that we ask the springsource team to
offer the template stuff for jms and jdbc as separate jars that don´t
need the rest of spring. I am sure this would benefit cxf as well as
camel. I will dig into the spring code a bit to check if this is
possible at all. I don´t know how much spring api they use in the
template stuff.
Greetings
Christian
Am 05.08.2010 08:25, schrieb Daniel Kulp:
Just a little history on this...
Originally, the JMS transport only used the JMS API's directly. I think the
version on the 2.0 branch still is that way. You may want to look at that as
a starting point if you need a custom version.
Around Aug/Sept 2008, Christian did a lot of work to refactor the entire thing
to use the Spring JMS stuff. There were a lot of deficiencies in the JMS
transport that were solved by doing that. We actually talked to the JMS
"experts" over on ActiveMQ and they all pretty much unanimously (James, Hiram,
etc....) agreed that to do JMS correctly, you use the Spring JMS stuff.
Never try to do good JMS without it. Thus, it was refactored to use Spring.
One of the JIRA's:
https://issues.apache.org/jira/browse/CXF-1832
If you scroll back to the Aug/Sep 2008 time frame in the email logs, there may
be more information. Unfortunately, my internet access/email access is almost
non-existent this week so I cannot really dig through right now.
Dan
On Tuesday 03 August 2010 4:48:59 am 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
