Re: JMS 1.0.2 support......
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
RE: JMS 1.0.2 support......
Hi Christian, Our configuration is wsdl based. Here is the service description: service name=HelloWorldServiceSonic port binding=tns:HelloWorldPortBinding name=HelloWorldPortSonic jms:address jndiConnectionFactoryName=SonicQueueConnectionFactory jndiDestinationName=SampleQ4 jms:JMSNamingProperty name=java.naming.factory.initial value=com.sonicsw.jndi.mfcontext.MFContextFactory / jms:JMSNamingProperty name=java.naming.provider.url value=tcp://pdsunfire.boston.amer.iona.com:2506 / /jms:address jms:server durableSubscriberName=CXF_subscriber/ /port /service Regards, Seumas -Original Message- From: Christian Schneider [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2008 2:11 AM To: Seumas Soltysik Cc: dev@cxf.apache.org; Daniel Kulp Subject: Re: JMS 1.0.2 support.. 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? -- Christian Schneider --- http://www.liquid-reality.de
RE: JMS 1.0.2 support......
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 [EMAIL PROTECTED] http://dankulp.com/blog
Re: JMS 1.0.2 support......
On Saturday 11 October 2008 3:34:52 am Christian Schneider wrote: Hi Dan, sounds reasonable to me. I have added the config element to address and set the default. I think setting useJms11 to false for 2.0.x and 2.1.x probably makes sense for compatibility sake. For 2.2 (trunk), it probably make sense to set the default to true. If the provider is 1.1 capable, we probably should use it, but provide the option for the user to downgrade to 1.0.2 if they need it. Dan Greetings Christian Daniel Kulp schrieb: 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 [EMAIL PROTECTED] http://dankulp.com/blog
