Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-375

Add callback functionality to transport connections

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.6
    • Component/s: Core
    • Labels:
      None

      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

        Activity

        jethrobakker Jethro Bakker created issue -
        arjen.poutsma Arjen Poutsma made changes -
        Field Original Value New Value
        Fix Version/s 1.6 [ 10981 ]
        Summary  Log attributes (like correlationId) of response JMS messages (send by SWS) Add callback functionality to transport connections
        arjen.poutsma Arjen Poutsma made changes -
        Remaining Estimate 0.5d [ 14400 ]
        Original Estimate 0.5d [ 14400 ]
        Hide
        mengugu Guillaume Menguy added a comment -

        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.

        Show
        mengugu Guillaume Menguy added a comment - 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.
        Hide
        jethrobakker Jethro Bakker added a comment -

        Solution:

        Add a callback to the following methods:

        Show
        jethrobakker Jethro Bakker added a comment - Solution: Add a callback to the following methods:
        Hide
        jethrobakker Jethro Bakker added a comment -

        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.

        Show
        jethrobakker Jethro Bakker added a comment - 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.
        Hide
        jethrobakker Jethro Bakker added a comment -

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

        Show
        jethrobakker Jethro Bakker added a comment - 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); }
        arjen.poutsma Arjen Poutsma made changes -
        Fix Version/s 1.6 M1 [ 11110 ]
        Fix Version/s 1.6 [ 10981 ]
        Hide
        pieni Pieter van der Meer added a comment -

        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.

        Show
        pieni Pieter van der Meer added a comment - 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.
        Hide
        pieni Pieter van der Meer added a comment -

        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

        Show
        pieni Pieter van der Meer added a comment - 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
        arjen.poutsma Arjen Poutsma made changes -
        Fix Version/s 1.6 M1 [ 11110 ]
        Fix Version/s 1.5.6 [ 11141 ]
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

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

        Show
        arjen.poutsma Arjen Poutsma added a comment - Fixed. JMS transport now allows for a org.springframework.jms.core.MessagePostProcessor to be injected, which can be used to change the message.
        arjen.poutsma Arjen Poutsma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        jethrobakker Jethro Bakker added a comment -

        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?

        Show
        jethrobakker Jethro Bakker added a comment - 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?
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Yes, that is correct.

        Show
        arjen.poutsma Arjen Poutsma added a comment - Yes, that is correct.
        Hide
        jethrobakker Jethro Bakker added a comment -

        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.

        Show
        jethrobakker Jethro Bakker added a comment - 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.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Closing old issues

        Show
        arjen.poutsma Arjen Poutsma added a comment - Closing old issues
        arjen.poutsma Arjen Poutsma made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        149d 21h 46m 1 Arjen Poutsma 12/Nov/08 11:33 PM
        Resolved Resolved Closed Closed
        1268d 7h 30m 1 Arjen Poutsma 04/May/12 7:03 AM

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            jethrobakker Jethro Bakker
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: