Review support for WMQ-transport

hdahl commented 9 years ago

Original issue 130 created by soi-toolkit on 2011-04-07T12:31:57.000Z:

See compensating code in:

org.soitoolkit.commons.mule.jms.ObjectToJMSMessageTransformer.setJmsProperties(...)

hdahl commented 9 years ago

Comment #1 originally posted by soi-toolkit on 2011-11-30T15:48:41.000Z:

Move to 0.5.1

hdahl commented 9 years ago

Comment #2 originally posted by soi-toolkit on 2012-04-06T07:52:37.000Z:

Moved to 0.5.2

hdahl commented 9 years ago

Comment #3 originally posted by soi-toolkit on 2012-04-06T07:53:29.000Z:

Moved to 0.5.2

hdahl commented 9 years ago

Comment #4 originally posted by soi-toolkit on 2012-04-23T09:07:09.000Z:

Also in need of review are:

import of transformers for jms-message to/from object since these are WMQ-specific
info-mapping for WMQ
transaction handling (jms: vs wmq:)

hdahl commented 9 years ago

Comment #5 originally posted by soi-toolkit on 2012-04-23T14:23:02.000Z:

Let's try to squeeze this one into the 0.5.1 release. Depends on time availability in customer project. GO Håkan GO :-)

hdahl commented 9 years ago

Comment #6 originally posted by soi-toolkit on 2012-04-24T13:13:08.000Z:

Also set up testcase for JMS-JMS using jms:transaction where the inbound message has a replyTo-destination set.

The outcome in Mule 2.2.5 (Mule 3 also suffers from this problem, possibly in some other way) is that a reply with a NullPayload is generated back to the application that sent the message (with JMSCorrelationID properly set ...) while the inbound message is also routed to the outbound endpoint. Problem not showing up in Mule 2.2.5 without jms:transaction, takes a different code-path for non-synchronous invocation.

Requires use of the MuleProperties.MULE_REPLY_TO_STOP_PROPERTY to stop this from happening, see: SedaService.doSend(MuleEvent).

See also: http://www.mulesoft.org/documentation/display/MULE/Mule+3.2.2+Release+Notes EE-2656, Transport: WebsphereMQ: WMQ (JMS?) sends responses to ReplyTo queues even if inbound-endpoint is one-way

hdahl commented 9 years ago

Comment #7 originally posted by soi-toolkit on 2012-04-24T13:43:14.000Z:

Add testcase: (JMS-JMS) check that inbound WMQ-properties does not infect the outbound

hdahl commented 9 years ago

Comment #8 originally posted by soi-toolkit on 2012-04-25T10:28:58.000Z:

The WMQ connector does not set persistentDelivery="true" like the AMQ-connector does, resulting in non-persistent messages being sent.

hdahl commented 9 years ago

Comment #9 originally posted by soi-toolkit on 2012-05-25T14:27:58.000Z:

This issue was updated by revision r1648.

added persistentDelivery="true" to WMQ-connector

hdahl commented 9 years ago

Comment #10 originally posted by soi-toolkit on 2012-06-07T11:39:35.000Z:

This issue was updated by revision r1651.

Updated wiki UG_WmqTransport to be inline with soi-tk 0.5.0 and Mule 3.2

hdahl commented 9 years ago

Comment #11 originally posted by soi-toolkit on 2012-06-07T11:55:01.000Z:

This issue was updated by revision r1652.

adding script for deploying wmq-libs

hdahl commented 9 years ago

Comment #12 originally posted by soi-toolkit on 2012-06-07T12:12:22.000Z:

This issue was updated by revision r1653.

Added link to script for deploy of WMQ-libs

hdahl commented 9 years ago

Comment #13 originally posted by soi-toolkit on 2012-06-15T14:00:57.000Z:

This issue was updated by revision r1660.

Adding reconnect-forever policy for WMQ-connector.

hdahl commented 9 years ago

Comment #14 originally posted by soi-toolkit on 2012-07-26T16:34:58.000Z:

Move open v0.5.1 issues to v0.6.0, since the next release will be v0.6.0 and not v0.5.1.

hdahl commented 9 years ago

Comment #15 originally posted by soi-toolkit on 2012-08-31T12:52:52.000Z:

Move to 0.6.2

hdahl commented 9 years ago

Won't fix. WMQ-transport is a Mule EE feature and requires a WMQ-installation, which means we can't have continuous testing for it.

soi-toolkit / soi-toolkit-mule

Review support for WMQ-transport #130