Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 89082 invoked from network); 11 Nov 2008 16:51:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Nov 2008 16:51:22 -0000 Received: (qmail 60317 invoked by uid 500); 11 Nov 2008 16:51:29 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 60297 invoked by uid 500); 11 Nov 2008 16:51:29 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 60286 invoked by uid 99); 11 Nov 2008 16:51:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Nov 2008 08:51:29 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.79.199.57] (HELO server.dankulp.com) (64.79.199.57) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Nov 2008 16:50:08 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 11649197CA1A; Tue, 11 Nov 2008 11:50:21 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5-gr0 (2008-06-10) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter.0eJbSLcGKI Received: from [192.168.1.140] (c-24-91-141-225.hsd1.ma.comcast.net [24.91.141.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTP id ECB37197C707; Tue, 11 Nov 2008 11:50:19 -0500 (EST) To: dev@cxf.apache.org Subject: Re: JMS 1.0.2 support...... Cc: Christian Schneider , Seumas Soltysik Content-Disposition: inline From: Daniel Kulp Date: Tue, 11 Nov 2008 11:50:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200811111150.22122.dkulp@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-0.7 required=3.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5-gr0 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:dkulp@apache.org] > > 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 dkulp@progress.com http://dankulp.com/blog -- Daniel Kulp dkulp@apache.org http://dankulp.com/blog