I think I see the issue.   If jms102 support is enabled, we need to create a 
SingleConnectionFactory102 instead of SingleConnectionFactory.  Probably 
should check the spring-jms jar for other classes ending in 102 to see if we 
need to change anything else.


Dan


On Tuesday 11 November 2008 2:11:13 am Christian Schneider wrote:
> Hi Seumas,
>
> could you post the configuration you used?
>
> Greetings
>
> Christian
>
> Seumas Soltysik schrieb:
> > I have just upgraded to CXF 2.1.3 and am running against an old
> > implementation of SonicMQ version 5, which I believe based upon the old
> > 1.0.2 apis. However, I am still getting a stack which indicates that CXF
> > does still not seem compatible with older versions of JMS. Clearly the
> > stack show that a JmsTemplate102 is being used, yet the problem I was
> > having with 2.1.2 persists.
> >
> > java.lang.AbstractMethodError:
> > progress.message.jclient.QueueConnectionFactory.createConnection()Ljavax
> > /jms/Connection;
> > at
> > org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapt
> > er.doCreateConnection(UserCredentialsConnectionFactoryAdapter.java:177)
> > at
> > org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapt
> > er.createConnection(UserCredentialsConnectionFactoryAdapter.java:149)
> > at
> > org.springframework.jms.connection.SingleConnectionFactory.doCreateConne
> > ction(SingleConnectionFactory.java:316)
> > at
> > org.springframework.jms.connection.SingleConnectionFactory.initConnectio
> > n(SingleConnectionFactory.java:270)
> > at
> > org.springframework.jms.connection.SingleConnectionFactory.createConnect
> > ion(SingleConnectionFactory.java:215)
> > at
> > org.springframework.jms.connection.SingleConnectionFactory.createQueueCo
> > nnection(SingleConnectionFactory.java:227)
> > at
> > org.springframework.jms.core.JmsTemplate102.createConnection(JmsTemplate
> > 102.java:170)
> > at
> > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:461)
> > at
> > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:436)
> > at
> > org.apache.cxf.transport.jms.JMSFactory.resolveOrCreateDestination(JMSFa
> > ctory.java:120)
> > at
> > org.apache.cxf.transport.jms.JMSFactory.createJmsListener(JMSFactory.jav
> > a:101)
> > at
> > org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java
> >
> > :99)
> >
> > at
> > org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractO
> > bservable.java:48)
> > at
> > org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindin
> > gFactory.java:166)
> > at
> > org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFa
> > ctory.java:721)
> > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:122)
> > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:263)
> > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:201)
> > at
> > org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderI
> > mpl.java:84)
> > at javax.xml.ws.Endpoint.publish(Endpoint.java:47)
> > -----Original Message-----
> > From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> > Sent: Friday, October 10, 2008 10:42 AM
> > To: Christian Schneider; dev@cxf.apache.org
> > Subject: JMS 1.0.2 support......
> >
> >
> > Christian,
> >
> > The old JMS transport pretty much just used the JMS 1.0.2 API's so it
> > worked
> > with old versions of JMS providers and such.   The new stuff seems to
> > default
> > to 1.1 which is causing issues.    I see that if you use the new config,
> > it's
> > settable.   However, if you use the old wsdl based stuff, it cannot.
> > I'm
> > wondering if it make sense for the line in JMSOldConfigHolder that
> > reads:
> >  jmsConfig.setUseJms11(true);
> > should be changed to false to be compatible with the old version?
> >
> > I suppose we could add a optional "useJms11" attribute (default to
> > false) on
> > one of the old extensors (address maybe?) to set this so if someone
> > wants to
> > use 1.1, they could, but default behavior is maintained.
> >
> > Thoughts?



-- 
Daniel Kulp
Software Fellow
Progress Software
[EMAIL PROTECTED]
http://dankulp.com/blog
-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

Reply via email to