Hi,
I got slightly confused by the documentation on how to configure
exchange (or queue) arguments by POJO using RabbitMQ.
The old way was to define an ArgsConfigurer but that has been marked
deprecated a while ago, as well as setExchangeArgs. JavaDoc says: "Use
args instead e.g arg.queue.x-message-ttl=1000". This implies that
providing a map using setArgs should work "at runtime" on an instance of
RabbitMQEndpoint.
However, this does *not* work:
RabbitMQEndpoint endpoint = ...;
Map<String, Object> args = new HashMap<>();
args.put("arg.exchange.x-recent-history-length", 1);
endpoint.setArgs(args);
I can see that in 2.23.0 the generic args map is only read out once
during RabbitMQComponent#createEndpoint which means args needs to be
final at construction time. Any later changes do not seem to be taken
into account. Internally, RabbitMQDeclareSupport still reads from
RabbitMQEndpoint#getExchangeArgs/getQueueArgs and both getter methods
have not been deprecated although their setters' JavaDoc refers to
generic args instead (same for set...ArgsConfigurer).
This works:
RabbitMQEndpoint endpoint = ...;
endpoint.getExchangeArgs().put("x-recent-history-length", 1);
Is that the correct way I should use if I don't want to provide the args
to the endpoint URL? It feels inconsistent to deprecation of the
same-named setter methods.
If it is, then it would be better to refer to
getExchangeArgs/getQueueArgs on setExchangeArgs/setQueueArgs JavaDoc.
If it's not the correct way, then getters should be marked deprecated as
well.
Also, it would be good to add a note to setArgs stating that the map is
only read once and thus calling the setter/changing the map has no
effect (thus it should not be called except by Camel) and, if the above
way is correct, getExchangeArgs/getQueueArgs need to be used instead in
such cases.
... or maybe everything should be adapted so any later changes to
generic args should actually have an effect?
Bye,
Daniel
