[SWS-375] Add callback functionality to transport connections Created: 16/Jun/08  Updated: 04/May/12  Resolved: 12/Nov/08

Status: Closed
Project: Spring Web Services
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.5.6

Type: Improvement Priority: Major
Reporter: Jethro Bakker Assignee: Arjen Poutsma
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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



 Comments   
Comment by Guillaume Menguy [ 23/Jun/08 ]

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.

Comment by Jethro Bakker [ 25/Jun/08 ]

Solution:

Add a callback to the following methods:

Comment by Jethro Bakker [ 25/Jun/08 ]

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.

Comment by Jethro Bakker [ 15/Aug/08 ]

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);
}

Comment by Pieter van der Meer [ 31/Oct/08 ]

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.

Comment by Pieter van der Meer [ 31/Oct/08 ]

Oops to quick on the add button.

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

Comment by Arjen Poutsma [ 12/Nov/08 ]

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

Comment by Jethro Bakker [ 20/Nov/08 ]

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?

Comment by Arjen Poutsma [ 20/Nov/08 ]

Yes, that is correct.

Comment by Jethro Bakker [ 20/Nov/08 ]

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.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sun Dec 17 21:35:45 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.