Qpid
  1. Qpid
  2. QPID-4707

[AMQP 1.0] provide means of setting more fields in a 1.0 formatted message

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.22
    • Fix Version/s: 0.23
    • Component/s: C++ Client
    • Labels:
      None

      Description

      To begin with, the various x-amqp-xxxx properties that are set on receiving a message should be recognised when sending a message also.

        Activity

        Hide
        Justin Ross added a comment -
        Show
        Justin Ross added a comment - Released in Qpid 0.24, http://qpid.apache.org/releases/qpid-0.24/index.html
        Hide
        Gordon Sim added a comment -

        ...qpid::data perhaps

        Show
        Gordon Sim added a comment - ...qpid::data perhaps
        Hide
        Gordon Sim added a comment -

        I agree that there is nothing that ties MapHandler (or CharSequence) to amqp specifically. It's there now mainly because I couldn't see a better place at present (I also agree the existing structure in general is not ideal). Possibly they could form the start of a new namespace - not sure what that should be called though...

        Show
        Gordon Sim added a comment - I agree that there is nothing that ties MapHandler (or CharSequence) to amqp specifically. It's there now mainly because I couldn't see a better place at present (I also agree the existing structure in general is not ideal). Possibly they could form the start of a new namespace - not sure what that should be called though...
        Hide
        Andrew Stitcher added a comment -

        Ah, I assumed that qpid::amqp was specific to the new amqp support code.

        My mental model was that you had chosen to call the new amqp 1.0 support just qpid::amqp because it supports the official standardised protocol rather than the pre-standard 0.10 etc. versions - this makes reasonable sense to me.

        But if I look at the code in qpid::amqp much of it is actually 1.0 specific irrespective of which library it gets built into.

        At present the only place in the current tree which isn't protocol specific and is shared between broker and client is qpid::sys which isn't a good name at all (and there is indeed stuff in there that isn't actually shared!)

        It would definitely be good to have a good set of rules about what goes where in the tree and then to move everything to suit.

        Show
        Andrew Stitcher added a comment - Ah, I assumed that qpid::amqp was specific to the new amqp support code. My mental model was that you had chosen to call the new amqp 1.0 support just qpid::amqp because it supports the official standardised protocol rather than the pre-standard 0.10 etc. versions - this makes reasonable sense to me. But if I look at the code in qpid::amqp much of it is actually 1.0 specific irrespective of which library it gets built into. At present the only place in the current tree which isn't protocol specific and is shared between broker and client is qpid::sys which isn't a good name at all (and there is indeed stuff in there that isn't actually shared!) It would definitely be good to have a good set of rules about what goes where in the tree and then to move everything to suit.
        Hide
        Gordon Sim added a comment -

        The qpid::amqp code is not part of 1.0 specific libraries, its compiled in to qpid common. The same interface is useful in both the client and the broker which is why I moved it. What package would you prefer? (I considered qpid::types, but this shouldn't be part of any public API/ABI yet and that package is compile into a separate library).

        Show
        Gordon Sim added a comment - The qpid::amqp code is not part of 1.0 specific libraries, its compiled in to qpid common. The same interface is useful in both the client and the broker which is why I moved it. What package would you prefer? (I considered qpid::types, but this shouldn't be part of any public API/ABI yet and that package is compile into a separate library).
        Hide
        Andrew Stitcher added a comment -

        I'm not sure that moving the MapHandler inteface from broker to amqp is correct.

        The interface is used by the protocol independent code to call visitors to the property maps in messages so I'd expect the interface itself to also be a protocol independent thing. The only other type that is affected is CharSequence and this is very simple and so could be in broker too.

        This change now has the effect of make the old 0_10 protocol implementation dependent on the new 1.0 implementation which strikes me as a bad idea (and easy to fix at this stage).

        Show
        Andrew Stitcher added a comment - I'm not sure that moving the MapHandler inteface from broker to amqp is correct. The interface is used by the protocol independent code to call visitors to the property maps in messages so I'd expect the interface itself to also be a protocol independent thing. The only other type that is affected is CharSequence and this is very simple and so could be in broker too. This change now has the effect of make the old 0_10 protocol implementation dependent on the new 1.0 implementation which strikes me as a bad idea (and easy to fix at this stage).
        Hide
        ASF subversion and git services added a comment -

        Commit 1489519 from gsim
        [ https://svn.apache.org/r1489519 ]

        QPID-4707: Set AMQP 1.0 fields on outgoing messages based on special property keys

        Show
        ASF subversion and git services added a comment - Commit 1489519 from gsim [ https://svn.apache.org/r1489519 ] QPID-4707 : Set AMQP 1.0 fields on outgoing messages based on special property keys

          People

          • Assignee:
            Gordon Sim
            Reporter:
            Gordon Sim
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development