Camel
  1. Camel
  2. CAMEL-4494

Allow replyTo message header to be different from actual reply queue

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.8.1
    • Fix Version/s: None
    • Component/s: camel-jms
    • Labels:
      None
    • Patch Info:
      Patch Available
    • Estimated Complexity:
      Unknown

      Description

      We have an application that acts as a JMS client in the following setup:

      • a local queue manager (L) with queues for request (L.REQUEST) and reply (L.REPLY) messages
      • a remote queue manager (R) with queues for request (R.REQUEST) and reply (R.REPLY) messages

      The remote queue manager is unknown to the client application, and messages sent to L.REQUEST are automatically forwarded to R.REQUEST. Similarly, there is a server application listening on R.REQUEST, posting responses in R.REPLY. The local queue manager is unknown to the server application. Messages sent to R.REPLY are automatically forwarded to L.REPLY.

      The client needs to put message in L.REQUEST and receive the reply in L.REPLY. However, in the message header it must set R.REPLY as the reply queue because L.REPLY is not known to the server application.

      The Camel JMS component currently doesn't seem to support this scenario.

      1. camel-jms-replyto.diff
        9 kB
        Jens Granseuer
      2. camel-jms-replyto2.diff
        10 kB
        Jens Granseuer

        Activity

        Hide
        Claus Ibsen added a comment -

        Yes you need to re-attach the file again.

        Show
        Claus Ibsen added a comment - Yes you need to re-attach the file again.
        Hide
        Jens Granseuer added a comment -

        Hm, I thought I had done so. There doesn't seem to be a way to change it without reuploading, though, correct?

        Show
        Jens Granseuer added a comment - Hm, I thought I had done so. There doesn't seem to be a way to change it without reuploading, though, correct?
        Hide
        Claus Ibsen added a comment -

        When attaching patches make sure to mark [x] in grant license to ASL, otherwise it cannot be used/accepted.

        Show
        Claus Ibsen added a comment - When attaching patches make sure to mark [x] in grant license to ASL, otherwise it cannot be used/accepted.
        Hide
        Jens Granseuer added a comment -

        Okay, so I noticed that the current code actually simply dynamically creates destinations if the endpoint doesn't have a resolver set. So I just did the same here.

        I would hope that this patch is actually fit for inclusion.

        Show
        Jens Granseuer added a comment - Okay, so I noticed that the current code actually simply dynamically creates destinations if the endpoint doesn't have a resolver set. So I just did the same here. I would hope that this patch is actually fit for inclusion.
        Hide
        David J. M. Karlsen added a comment -

        I definetly think it should use a DestinationResolver as the rest is spring based - and this is the strategy interface for destination resolving.

        This will allow for custom resolving:

        I have an custom implementation of a DestinationResolver in order to be able to set WMQ (WebSphere MQ) specific stuff on resolved queues.

        Where can I donate that code?
        It currently relies on some small parts of IBM code, but I could change that to being reflection based.

        Show
        David J. M. Karlsen added a comment - I definetly think it should use a DestinationResolver as the rest is spring based - and this is the strategy interface for destination resolving. This will allow for custom resolving: I have an custom implementation of a DestinationResolver in order to be able to set WMQ (WebSphere MQ) specific stuff on resolved queues. Where can I donate that code? It currently relies on some small parts of IBM code, but I could change that to being reflection based.
        Hide
        Jens Granseuer added a comment -

        Here's a (fairly naive) implementation of this feature. The included test case works for me but I'm not sure of the proper way to get hold of a DestinationResolver when setting the header (see FIXMEs in the patch). I'm also not fond of the name of the new configuration property.

        Please let me know if you have any suggestions.

        Show
        Jens Granseuer added a comment - Here's a (fairly naive) implementation of this feature. The included test case works for me but I'm not sure of the proper way to get hold of a DestinationResolver when setting the header (see FIXMEs in the patch). I'm also not fond of the name of the new configuration property. Please let me know if you have any suggestions.
        Hide
        Jens Granseuer added a comment -

        Or consider the case where I am just trying to proxy a (obviously synchronous) HTTP request/reply pair via JMS. I'm not sure if that can even be done with two separate routes.

        Show
        Jens Granseuer added a comment - Or consider the case where I am just trying to proxy a (obviously synchronous) HTTP request/reply pair via JMS. I'm not sure if that can even be done with two separate routes.
        Hide
        Jens Granseuer added a comment - - edited

        Hi Heath,

        yes, I guess this could be done using separate routes instead. Doing it in one synchronous route, however, does provide a few advantages, e.g. being able to access context information from the request not to mention that it simply results in a simpler route setup.

        Show
        Jens Granseuer added a comment - - edited Hi Heath, yes, I guess this could be done using separate routes instead. Doing it in one synchronous route, however, does provide a few advantages, e.g. being able to access context information from the request not to mention that it simply results in a simpler route setup.
        Hide
        Heath Kesler added a comment -

        Hi Jens, are you trying to set this up as a single synchronous route? You can set it up asynchronously using multiple routes fairly easily. Just trying to clarify your use case.

        Show
        Heath Kesler added a comment - Hi Jens, are you trying to set this up as a single synchronous route? You can set it up asynchronously using multiple routes fairly easily. Just trying to clarify your use case.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jens Granseuer
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development