Hi Christian Indeed, I can see JMSDestination & JMSFactory importing a lot of Spring classes, so my last commit was futile, I started working yesterday on the test which I did not finish, but that work will need to be parked for now...
In fact, I was definitely blind yesterday, removed InitializingBean from JMSConfiguration which still imports a bunch of other Spring classes. That did fix the deployment issue per se to the container instance with no Spring available but as Willem mentioned it did not make any sense in the end... So I guess given that CXF JMS transport can not be used in non-Spring deployments then a custom JMS transport would need to be created instead... cheers, Sergey On Tue, Aug 3, 2010 at 9:35 PM, Christian Schneider <ch...@die-schneider.net > wrote: > 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<willem.ji...@gmail.com >> >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 > >
