Add callback functionality to transport connections [SWS-375]

[gregturn]

Jethro Bakker opened SWS-375 and commented

We are using the WebserviceMessageListener and I would like to log the header attributes (like correlationId and replyTo) of the incomming and outgoing JMS messages.

I can log the header values of incomming messages by extending the WebserviceMessageListener but the response messages are created within the spring ws framework.

It would be nice if you can manipulate, or log the JMS Message before it is send by the message producer.

Possible solution: Add callback functionality to the JmsReceiverConnection

---

Referenced from: commits e2e9456

3 votes, 4 watchers

[gregturn]

Guillaume Menguy commented

I completely agree. Typically in JMS message headers are very useful when browsing the queue to identify a specific message using a business identifier (middleware independant) without having to parse the payload, it would be nice to allow to set the same header in the response.

[gregturn]

Jethro Bakker commented

Solution:

Add a callback to the following methods:

[gregturn]

Jethro Bakker commented

Submitted to quick.

I am working on a solution to this problem because in our project we need this functionality. We can not wait till the 1.6 release.

[gregturn]

Jethro Bakker commented

I have downloaded the source code from subversion and created a solution.

First I created an interface called TransportCallback with the following methods:

void doWithTransportAfterRead(AbstractWebServiceConnection connection);

void doWithTransportAfterWrite(AbstractWebServiceConnection connection);

I have added a callback instance to the the AbstractWebServiceConnection class, so all connections can call the transport callback. I wanted to log jms responses, so it was necessary to adjust the JmsReceiverConnection, I have added a couple of constructors with an extra paramter TransportCallback. Finally the onSendAfterWrite calls the doWithTransportAfterWrite(this):

if (requestMessage.getJMSReplyTo() != null) {
messageProducer = session.createProducer(requestMessage.getJMSReplyTo());
messageProducer.setDeliveryMode(requestMessage.getJMSDeliveryMode());
messageProducer.setPriority(requestMessage.getJMSPriority());
if(callback != null){
callback.doWithTransportBeforeWrite(this);
}
messageProducer.send(responseMessage);
}

[gregturn]

Pieter van der Meer commented

I'm dealing with the same problem. A must add properties to the JMS message send from the client.
I chose not to change the SWS code base but implement my own MessageSender and SenderConnection. This enables me to also implement a fire forget alternatif into the Sender.
Added additional parameter to make the send/recieve methods not to wait for a response.

[gregturn]

Pieter van der Meer commented

Oops to quick on the add button.

The last part of the comment is similar to #317. That is implement one-way/in-only/fire-forget style messaging

[gregturn]

Arjen Poutsma commented

Fixed. JMS transport now allows for a org.springframework.jms.core.MessagePostProcessor to be injected, which can be used to change the message.

[gregturn]

Jethro Bakker commented

It is now possible to change/log the outgoing message but I think it is still not possible to log incomming messages with its attributes. Is this a correct conclusion?

[gregturn]

Arjen Poutsma commented

Yes, that is correct.

[gregturn]

Jethro Bakker commented

Ok.

We want to do the following: If an expiration time is set on the request message than we have to set also an expiration time on the response message. The value of the expiration time is calculated as follows: time of request expiration minus current time.

We want such a solution because the request sender determines the time the sending system is waiting on the response message. When this system times out the response message must directly expire on the queue.

But with the current solution this is not possible, because you can not correlate request and response message.

[gregturn]

Arjen Poutsma commented

Closing old issues