[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2018-01-28 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342532#comment-16342532
 ] 

ASF GitHub Bot commented on CXF-7023:
-

cschneider commented on issue #358: [CXF-7023] Add oneSessionPerConnection 
property to JMS transport
URL: https://github.com/apache/cxf/pull/358#issuecomment-361055265
 
 
   Looks .. good I merged it


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SOAP over JMS transport does not use XA transactions with Websphere MQ 
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
>  Issue Type: Bug
>  Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>Assignee: Christian Schneider
>Priority: Major
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms 
> connection, but connection opened in JMSDestination, and transaction started 
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may 
> be there are better way to provide support for WMQ adapter? 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2018-01-28 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342533#comment-16342533
 ] 

ASF GitHub Bot commented on CXF-7023:
-

cschneider closed pull request #358: [CXF-7023] Add oneSessionPerConnection 
property to JMS transport
URL: https://github.com/apache/cxf/pull/358
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
index a83984b8f99..5a9550181eb 100644
--- 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
+++ 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
@@ -54,14 +54,19 @@
 private static final Logger LOG = 
LogUtils.getL7dLogger(BackChannelConduit.class);
 private JMSConfiguration jmsConfig;
 private Message inMessage;
-private Connection connection;
+private Connection persistentConnection;
 
 BackChannelConduit(Message inMessage, JMSConfiguration jmsConfig, 
Connection connection) {
 super(EndpointReferenceUtils.getAnonymousEndpointReference());
 this.inMessage = inMessage;
 this.jmsConfig = jmsConfig;
-this.connection = connection;
+this.persistentConnection = connection;
 }
+
+BackChannelConduit(Message inMessage, JMSConfiguration jmsConfig) {
+this(inMessage, jmsConfig, null);
+}
+
 @Override
 public void close(Message msg) throws IOException {
 MessageStreamUtil.closeStreams(msg);
@@ -121,6 +126,14 @@ public void sendExchange(Exchange exchange, final Object 
replyObj) {
 
 private void send(final Message outMessage, final Object replyObj, 
ResourceCloser closer)
 throws JMSException {
+Connection connection;
+
+if (persistentConnection == null) {
+connection = 
closer.register(JMSFactory.createConnection(jmsConfig));
+} else {
+connection = this.persistentConnection;
+}
+
 Session session = closer.register(connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE));
 
 JMSMessageHeadersType outProps = 
(JMSMessageHeadersType)outMessage.get(JMS_SERVER_RESPONSE_HEADERS);
@@ -178,6 +191,7 @@ public static void 
initResponseMessageProperties(JMSMessageHeadersType messagePr
 
messageProperties.setJMSDeliveryMode(inMessageProperties.getJMSDeliveryMode());
 messageProperties.setJMSPriority(inMessageProperties.getJMSPriority());
 
messageProperties.setSOAPJMSRequestURI(inMessageProperties.getSOAPJMSRequestURI());
+
messageProperties.setSOAPJMSSOAPAction(inMessageProperties.getSOAPJMSSOAPAction());
 messageProperties.setSOAPJMSBindingVersion("1.0");
 }
 
@@ -220,4 +234,4 @@ public String determineCorrelationID(javax.jms.Message 
request) throws JMSExcept
 : request.getJMSCorrelationID();
 }
 
-}
\ No newline at end of file
+}
diff --git 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java
index 50db27d0875..d627c1621c0 100644
--- 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java
+++ 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java
@@ -47,10 +47,12 @@
 import org.apache.cxf.message.MessageUtils;
 import org.apache.cxf.security.SecurityContext;
 import org.apache.cxf.transport.AbstractConduit;
+import org.apache.cxf.transport.jms.util.AbstractMessageListenerContainer;
 import org.apache.cxf.transport.jms.util.JMSListenerContainer;
 import org.apache.cxf.transport.jms.util.JMSSender;
 import org.apache.cxf.transport.jms.util.JMSUtil;
 import org.apache.cxf.transport.jms.util.MessageListenerContainer;
+import org.apache.cxf.transport.jms.util.PollingMessageListenerContainer;
 import org.apache.cxf.transport.jms.util.ResourceCloser;
 import org.apache.cxf.ws.addressing.EndpointReferenceType;
 
@@ -157,8 +159,16 @@ public void sendExchange(final Exchange exchange, final 
Object request) {
 assertIsNotTextMessageAndMtom(outMessage);
 
 try (ResourceCloser closer = new ResourceCloser()) {
-Connection c = getConnection();
-Session session = closer.register(c.createSession(false,
+Connection c;
+
+if (jmsConfig.isOneSessionPerConnection()) {
+c = closer.register(JMSFactory.createConnection(jmsConfig));
+c.start();
+} else {
+c = getConnection();
+}
+
+Ses

[jira] [Updated] (CXF-7621) Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11

2018-01-28 Thread Dennis Kieselhorst (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Kieselhorst updated CXF-7621:

Priority: Major  (was: Blocker)

> Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11
> -
>
> Key: CXF-7621
> URL: https://issues.apache.org/jira/browse/CXF-7621
> Project: CXF
>  Issue Type: Bug
>Reporter: Kirti
>Priority: Major
> Fix For: NeedMoreInfo
>
>
> Hi,
>  *I am working on upgrading java from 6 to 8 and WebSphere from 8.5.5.3 to 
> 8.5.5.11 . Facing below issue while hitting web services wsdl.*
> *Currently we are using spring 2.5 and apache cxf 2.3.9. Please suggest.*
> *2018-01-22 13:40:16,046 [server.startup : 2] ERROR 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:331)
>  - Context initializat*
>  *ion failed*
>  *org.springframework.beans.factory.BeanCreationException: Error creating 
> bean with name 'BOSService': Invocation of init method failed; nested 
> exception is javax.xml.ws.*
>  *WebServiceException: 
> org.apache.cxf.service.factory.ServiceConstructionException*
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1572)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
>  at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
>  at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755)
>  at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:762)
>  at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
>  at 
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:434)
>  at 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
>  at 
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106)
>  at 
> com.vesystems.ws.services.impl.CustomContextLoaderListener.contextInitialized(Unknown
>  Source)
>  at 
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1732)
>  at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:415)
>  at 
> com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
>  at 
> com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171)
>  at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904)
>  at 
> com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CXF-7621) Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11

2018-01-28 Thread Dennis Kieselhorst (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Kieselhorst updated CXF-7621:

Fix Version/s: NeedMoreInfo

> Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11
> -
>
> Key: CXF-7621
> URL: https://issues.apache.org/jira/browse/CXF-7621
> Project: CXF
>  Issue Type: Bug
>Reporter: Kirti
>Priority: Major
> Fix For: NeedMoreInfo
>
>
> Hi,
>  *I am working on upgrading java from 6 to 8 and WebSphere from 8.5.5.3 to 
> 8.5.5.11 . Facing below issue while hitting web services wsdl.*
> *Currently we are using spring 2.5 and apache cxf 2.3.9. Please suggest.*
> *2018-01-22 13:40:16,046 [server.startup : 2] ERROR 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:331)
>  - Context initializat*
>  *ion failed*
>  *org.springframework.beans.factory.BeanCreationException: Error creating 
> bean with name 'BOSService': Invocation of init method failed; nested 
> exception is javax.xml.ws.*
>  *WebServiceException: 
> org.apache.cxf.service.factory.ServiceConstructionException*
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1572)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
>  at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
>  at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755)
>  at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:762)
>  at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
>  at 
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:434)
>  at 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
>  at 
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106)
>  at 
> com.vesystems.ws.services.impl.CustomContextLoaderListener.contextInitialized(Unknown
>  Source)
>  at 
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1732)
>  at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:415)
>  at 
> com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
>  at 
> com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171)
>  at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904)
>  at 
> com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CXF-7621) Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11

2018-01-28 Thread Dennis Kieselhorst (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342573#comment-16342573
 ] 

Dennis Kieselhorst commented on CXF-7621:
-

Please provide more information (e.g. complete stacktrace, increase loglevel, 
reproducible testcase). Thank you.

> Facing issue while upgrading to Java 8 and Webspehre 8.5.5.11
> -
>
> Key: CXF-7621
> URL: https://issues.apache.org/jira/browse/CXF-7621
> Project: CXF
>  Issue Type: Bug
>Reporter: Kirti
>Priority: Major
> Fix For: NeedMoreInfo
>
>
> Hi,
>  *I am working on upgrading java from 6 to 8 and WebSphere from 8.5.5.3 to 
> 8.5.5.11 . Facing below issue while hitting web services wsdl.*
> *Currently we are using spring 2.5 and apache cxf 2.3.9. Please suggest.*
> *2018-01-22 13:40:16,046 [server.startup : 2] ERROR 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:331)
>  - Context initializat*
>  *ion failed*
>  *org.springframework.beans.factory.BeanCreationException: Error creating 
> bean with name 'BOSService': Invocation of init method failed; nested 
> exception is javax.xml.ws.*
>  *WebServiceException: 
> org.apache.cxf.service.factory.ServiceConstructionException*
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1572)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
>  at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
>  at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
>  at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
>  at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755)
>  at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:762)
>  at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
>  at 
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:434)
>  at 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
>  at 
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106)
>  at 
> com.vesystems.ws.services.impl.CustomContextLoaderListener.contextInitialized(Unknown
>  Source)
>  at 
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1732)
>  at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:415)
>  at 
> com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
>  at 
> com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:171)
>  at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904)
>  at 
> com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2018-01-28 Thread Dennis Kieselhorst (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Kieselhorst updated CXF-7023:

Fix Version/s: 3.2.2

> SOAP over JMS transport does not use XA transactions with Websphere MQ 
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
>  Issue Type: Bug
>  Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>Assignee: Christian Schneider
>Priority: Major
> Fix For: 3.2.2
>
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms 
> connection, but connection opened in JMSDestination, and transaction started 
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may 
> be there are better way to provide support for WMQ adapter? 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CXF-7623) AsynchHTTPConduit setupConnection - timeout settings

2018-01-28 Thread Dennis Kieselhorst (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Kieselhorst updated CXF-7623:

Fix Version/s: 3.2.2

> AsynchHTTPConduit setupConnection - timeout settings
> 
>
> Key: CXF-7623
> URL: https://issues.apache.org/jira/browse/CXF-7623
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Reporter: Antonin Fischer
>Priority: Minor
> Fix For: 3.2.2
>
>
> Class AsynchHTTPConduit method setupConnection(). Codeblock:
> {code:java}
> RequestConfig.Builder b = RequestConfig.custom()
>     .setConnectTimeout((int) csPolicy.getConnectionTimeout())
>     .setSocketTimeout((int) csPolicy.getReceiveTimeout())
>     .setConnectionRequestTimeout((int) 
> csPolicy.getReceiveTimeout());
> {code}
> Line *setConnectionRequestTimeout((int) csPolicy.getReceiveTimeout())*
> Settings of request timeout with receive timeout is not backward compatible 
> solution. In addition the receive timeout is in many times to long. Better 
> way is set the *request timeout by connection timeout* instead of it. It is 
> still compromis solution.
> HTTPClientPolicy object still doesn't contain request timeout. Think about 
> extension of domain objects about request timeout which is already used in 
> pools etc.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2018-01-28 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342574#comment-16342574
 ] 

ASF GitHub Bot commented on CXF-7023:
-

deki commented on issue #166: [CXF-7023] JMS transport new parameter 
"oneSessionPerConnection" need…
URL: https://github.com/apache/cxf/pull/166#issuecomment-361065432
 
 
   #358 has been merged, so this is obsolet.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> SOAP over JMS transport does not use XA transactions with Websphere MQ 
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
>  Issue Type: Bug
>  Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>Assignee: Christian Schneider
>Priority: Major
> Fix For: 3.2.2
>
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms 
> connection, but connection opened in JMSDestination, and transaction started 
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may 
> be there are better way to provide support for WMQ adapter? 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2018-01-28 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342575#comment-16342575
 ] 

ASF GitHub Bot commented on CXF-7023:
-

deki closed pull request #166: [CXF-7023] JMS transport new parameter 
"oneSessionPerConnection" need…
URL: https://github.com/apache/cxf/pull/166
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
index cb6746018c1..8a3a8606d9b 100644
--- 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
+++ 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/BackChannelConduit.java
@@ -64,6 +64,13 @@
 this.jmsConfig = jmsConfig;
 this.connection = connection;
 }
+
+BackChannelConduit(Message inMessage, JMSConfiguration jmsConfig) {
+super(EndpointReferenceUtils.getAnonymousEndpointReference());
+this.inMessage = inMessage;
+this.jmsConfig = jmsConfig;
+}
+
 @Override
 public void close(Message msg) throws IOException {
 MessageStreamUtil.closeStreams(msg);
@@ -123,7 +130,14 @@ public void sendExchange(Exchange exchange, final Object 
replyObj) {
 
 private void send(final Message outMessage, final Object replyObj, 
ResourceCloser closer)
 throws JMSException {
-Session session = closer.register(connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE));
+
+Connection c;
+if (jmsConfig.isOneSessionPerConnection()) {
+c = closer.register(JMSFactory.createConnection(jmsConfig));
+} else {
+c = this.connection;
+}
+Session session = closer.register(c.createSession(false, 
Session.AUTO_ACKNOWLEDGE));
 
 JMSMessageHeadersType outProps = 
(JMSMessageHeadersType)outMessage.get(JMS_SERVER_RESPONSE_HEADERS);
 JMSMessageHeadersType inProps = 
(JMSMessageHeadersType)inMessage.get(JMS_SERVER_REQUEST_HEADERS);
@@ -180,6 +194,7 @@ public static void 
initResponseMessageProperties(JMSMessageHeadersType messagePr
 
messageProperties.setJMSDeliveryMode(inMessageProperties.getJMSDeliveryMode());
 messageProperties.setJMSPriority(inMessageProperties.getJMSPriority());
 
messageProperties.setSOAPJMSRequestURI(inMessageProperties.getSOAPJMSRequestURI());
+
messageProperties.setSOAPJMSSOAPAction(inMessageProperties.getSOAPJMSSOAPAction());
 messageProperties.setSOAPJMSBindingVersion("1.0");
 }
 
diff --git 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java
index 9a0f4be0344..0bc50979515 100644
--- 
a/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java
+++ 
b/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java
@@ -46,10 +46,12 @@
 import org.apache.cxf.message.MessageUtils;
 import org.apache.cxf.security.SecurityContext;
 import org.apache.cxf.transport.AbstractConduit;
+import org.apache.cxf.transport.jms.util.AbstractMessageListenerContainer;
 import org.apache.cxf.transport.jms.util.JMSListenerContainer;
 import org.apache.cxf.transport.jms.util.JMSSender;
 import org.apache.cxf.transport.jms.util.JMSUtil;
 import org.apache.cxf.transport.jms.util.MessageListenerContainer;
+import org.apache.cxf.transport.jms.util.PollingMessageListenerContainer;
 import org.apache.cxf.transport.jms.util.ResourceCloser;
 import org.apache.cxf.ws.addressing.EndpointReferenceType;
 
@@ -135,7 +137,17 @@ public void sendExchange(final Exchange exchange, final 
Object request) {
 assertIsNotTextMessageAndMtom(outMessage);
 
 try (ResourceCloser closer = new ResourceCloser()) {
-Connection c = getConnection();
+Connection c;
+if (jmsConfig.isOneSessionPerConnection()) {
+try {
+c = 
closer.register(JMSFactory.createConnection(jmsConfig));
+} catch (JMSException e) {
+throw JMSUtil.convertJmsException(e);
+}
+c.start();
+} else {
+c = getConnection();
+}
 Session session = closer.register(c.createSession(false, 
   
Session.AUTO_ACKNOWLEDGE));
 
@@ -146,8 +158,10 @@ public void sendExchange(final Exchange exchange, final 
Object request) {
 }
 } catch (JMSException e) {
 // Cl

[jira] [Resolved] (CXF-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter

2018-01-28 Thread Dennis Kieselhorst (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Kieselhorst resolved CXF-7023.
-
Resolution: Fixed

[~nikolobok] [~rainer.mueller] [~vrlgohel] [~dalbotex] could you please check 
the latest version from master? [~ch...@die-schneider.net] merged a PR today. 
Please reopen this issue, if it's still not working for you...

> SOAP over JMS transport does not use XA transactions with Websphere MQ 
> resource adapter
> ---
>
> Key: CXF-7023
> URL: https://issues.apache.org/jira/browse/CXF-7023
> Project: CXF
>  Issue Type: Bug
>  Components: JMS
>Affects Versions: 3.1.7
>Reporter: Nikolay Boklaschuk
>Assignee: Christian Schneider
>Priority: Major
> Fix For: 3.2.2
>
>
> When using Websphere MQ resource adapter
> Inbound one-way service does not uses XA transactions.
> This is because WMQ adapter decides to use XA transaction when creates jms 
> connection, but connection opened in JMSDestination, and transaction started 
> in PollingMessageListnerContainer after connection created.
> Futhermore WMQ adapter holds only one session per connection.
> I have patched XAPoller to hold connection for each thread, it works, but may 
> be there are better way to provide support for WMQ adapter? 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CXF-7623) AsynchHTTPConduit setupConnection - timeout settings

2018-01-28 Thread Dennis Kieselhorst (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342581#comment-16342581
 ] 

Dennis Kieselhorst commented on CXF-7623:
-

This has been merged as part of a PR https://github.com/apache/cxf/pull/190 as 
fix for CXF-7122. [~willymontaz] [~ffang] can you please take a look?

> AsynchHTTPConduit setupConnection - timeout settings
> 
>
> Key: CXF-7623
> URL: https://issues.apache.org/jira/browse/CXF-7623
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Reporter: Antonin Fischer
>Priority: Minor
> Fix For: 3.2.2
>
>
> Class AsynchHTTPConduit method setupConnection(). Codeblock:
> {code:java}
> RequestConfig.Builder b = RequestConfig.custom()
>     .setConnectTimeout((int) csPolicy.getConnectionTimeout())
>     .setSocketTimeout((int) csPolicy.getReceiveTimeout())
>     .setConnectionRequestTimeout((int) 
> csPolicy.getReceiveTimeout());
> {code}
> Line *setConnectionRequestTimeout((int) csPolicy.getReceiveTimeout())*
> Settings of request timeout with receive timeout is not backward compatible 
> solution. In addition the receive timeout is in many times to long. Better 
> way is set the *request timeout by connection timeout* instead of it. It is 
> still compromis solution.
> HTTPClientPolicy object still doesn't contain request timeout. Think about 
> extension of domain objects about request timeout which is already used in 
> pools etc.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CXF-7623) AsynchHTTPConduit setupConnection - timeout settings

2018-01-28 Thread Antonin Fischer (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342620#comment-16342620
 ] 

Antonin Fischer commented on CXF-7623:
--

*Fixes*
 * Fix socket timeout and connection request timeout from AsyncHTTPClient
 * Fix AsyncHTTPConduit read timeout with exhausted connection pool

These changes are important for correct working of read timeout if the pool is 
busy. The corrections are ok, but it brings incompatible problems with previous 
timeouts. There is just one problem - the attachment of *RECEIVE* timeout as 
Request timeout:
.setConnectionRequestTimeout((int) csPolicy.getReceiveTimeout());
The receive timeout is alwayss the bigger number and it is not correct to use 
receive timeout for request timeout which is about waiting to pool.

There are two solutions:
 * Insert the connection timeout instead of receive timeout. This is compromise 
solution.
 * Extend the csPolicy domain object for new request timeout and handle the 
request timeout separately. This is best solution.

 

> AsynchHTTPConduit setupConnection - timeout settings
> 
>
> Key: CXF-7623
> URL: https://issues.apache.org/jira/browse/CXF-7623
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Reporter: Antonin Fischer
>Priority: Minor
> Fix For: 3.2.2
>
>
> Class AsynchHTTPConduit method setupConnection(). Codeblock:
> {code:java}
> RequestConfig.Builder b = RequestConfig.custom()
>     .setConnectTimeout((int) csPolicy.getConnectionTimeout())
>     .setSocketTimeout((int) csPolicy.getReceiveTimeout())
>     .setConnectionRequestTimeout((int) 
> csPolicy.getReceiveTimeout());
> {code}
> Line *setConnectionRequestTimeout((int) csPolicy.getReceiveTimeout())*
> Settings of request timeout with receive timeout is not backward compatible 
> solution. In addition the receive timeout is in many times to long. Better 
> way is set the *request timeout by connection timeout* instead of it. It is 
> still compromis solution.
> HTTPClientPolicy object still doesn't contain request timeout. Think about 
> extension of domain objects about request timeout which is already used in 
> pools etc.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)