I'm currently trying to send messages from amqp.node to a Java Spring Application, that expects an header as long, see this listener for example:
@RabbitListener(queues = "testQueue")
public void handleRequest(@Payload RequestBean bean, @Header("trace-id") long traceId) {
// some logic here...
}
I'm getting a type mismatch exception when the handleRequest method gets called, since the expected type for trace-id is long (64-bit integer), but it arrives as byte (8-bit integer). I found that this behaviour is implemented here, and at the moment there is no way to force the number type from outside.
I think the codec may handle these special cases like it does for timestamp (see here and here), by adding 'int8', 'int16', 'int32' and 'int64' to that switch-case block, and let the user choose the right integer type if needed. The existing heuristic may not be changed, to avoid a breaking change.
So, I may write something like this:
var options = {
headers: {
'trace-id': {'!': 'int64', value: 12}
},
contentType: 'application/json',
contentEncoding: 'UTF-8'
};
channel.publish('myExchange', 'routing.key', new Buffer(JSON.stringify(message)), options);
I'm currently trying to send messages from amqp.node to a Java Spring Application, that expects an header as
long, see this listener for example:I'm getting a type mismatch exception when the
handleRequestmethod gets called, since the expected type fortrace-idislong(64-bit integer), but it arrives asbyte(8-bit integer). I found that this behaviour is implemented here, and at the moment there is no way to force the number type from outside.I think the codec may handle these special cases like it does for
timestamp(see here and here), by adding'int8','int16','int32'and'int64'to that switch-case block, and let the user choose the right integer type if needed. The existing heuristic may not be changed, to avoid a breaking change.So, I may write something like this: