Page History

...

Task	Complete?	Estimate	Sprint	Notes
`clearBody()`	Later			To be implemented with each message type implementation
`clearProperties()`		2h		Additional handling to be added for custom vendor properties as they are individually implemented.
`getPropertyNames()` `propertyExists``(java.lang.String name)` `getBooleanProperty(java.lang.String name)` `getByteProperty(java.lang.String name)` `getDoubleProperty(java.lang.String name)` `getFloatProperty(java.lang.String name)` `getIntProperty(java.lang.String name)` `getLongProperty``(java.lang.String name)` `getObjectProperty``(java.lang.String name)` `getShortProperty(java.lang.String name)` `getStringProperty(java.lang.String name)` `setBooleanProperty(java.lang.String name, boolean value)` `setByteProperty(java.lang.String name, byte value)` `setDoubleProperty(java.lang.String name, double value)` `setFloatProperty(java.lang.String name, float value)` `setIntProperty(java.lang.String name, int value)` `setLongProperty(java.lang.String name, long value)` `setObjectProperty(java.lang.String name, java.lang.Object value)` `setShortProperty(java.lang.String name, short value)` `setStringProperty(java.lang.String name, java.lang.String value)`		2h
`getJMSMessageID()` `setJMSMessageID(java.lang.String id)`		1d		Requires an encoding/decoding scheme to be developed to allow retaining the underlying type information, as AMQP message-ids/correlation-ids can be a number of different types.
`getJMSCorrelationID()` `getJMSCorrelationIDAsBytes()` `setJMSCorrelationID(java.lang.String correlationID)` `setJMSCorrelationIDAsBytes(byte[] correlationID)`		4d		Requires an encoding/decoding scheme to be developed to allow retaining the underlying type information, as AMQP message-ids/correlation-ids can be a number of different types.
`getJMSDeliveryMode()` `setJMSDeliveryMode(int deliveryMode)`	but -->			There is still scope for optimizing NON_PERSISTENT messages by removing the AMQP header if all fields are at their default values and can be omitted.
`getJMSReplyTo()` `setJMSReplyTo(Destination replyTo)`	but -->			The prototypes transmission of destination-type information is rather verbose. There is scope to change this in order to significantly reduce the added per-message overhead.
`getJMSDestination()` `setJMSDestination(Destination destination)`	but -->			The prototypes transmission of destination-type information is rather verbose. There is scope to change this in order to significantly reduce the added per-message overhead.
`getJMSExpiration()` `setJMSExpiration(long expiration)`
`getJMSPriority()` `setJMSPriority(int priority)`
`getJMSRedelivered()` `setJMSRedelivered(boolean redelivered)`	Later			Somewhat dependant on implementing AMQP delivery-count header handling. setJMSRelivered makes no sense as the spec explicitly says you dont use it when sending messages (yours or foreign).
`getJMSTimestamp()` `setJMSTimestamp(long timestamp)`
`getJMSType()` `setJMSType(java.lang.String type)`		4h
`acknowledge()`	Later			As part of implementing Client-Ack sessions.
JMSXUserId		2h		[1]
JMSXGroupID		2h		[1]
JMSXGroupSeq		2h		[1]
JMSXDeliveryCount	Later			As part of Session redelivery etc. [1].
JMS_AMQP_TTL				[1]
JMS_AMQP_FIRST_ACQUIRER	Later		2h		[1]
JMS_AMQP_SUBJECT	Later	2h		[1]
JMS_AMQP_CONTENT_TYPE	Later		4h		[1]
JMS_AMQP_CONTENT_ENCODING	Later		4h		TODO: only on BytesMessage? [1]
JMS_AMQP_REPLY_TO_GROUP_ID		2h		[1]

...

[1] Handling will be required to deal with clashes where entries exist in the AMQP application-properties section with the same property name as would be used to access the relevant information which was actually carried on the AMQP header/properties. (e.g group information relating to JMSXGroupId will be carried in the AMQP properties section, so what happens when there is an application-properties entry with that key).

Phase 1: Remap-keys:

Property name prefix example: JMS_AMQP_PROP_<MANGLED>

...

Child pages

Versions Compared

Old Version 28

New Version 29

Key