I believe the semantics are first-match, not
merge-all-matches-overwriting-conflicts (e.g. how Spring loads properties)
and not merge-all-matches-not-overwriting-conflicts (e.g. how Ant loads
properties).
You could request the ability to select a different semantic (which would
require someone to implement any semantics other than first-match) through
a JIRA enhancement request, if you want that. In the meantime, put your
more-specific match first and include all the content of the generic case
along with the things that are specific.
Tim
On Jun 10, 2016 2:54 AM, "Johan Carlquist" <jo...@su.se> wrote:
Hi!
Our config:
=====
[...]
<policyEntries>
<policyEntry queue=">" >
<networkBridgeFilterFactory>
<conditionalNetworkBridgeFilterFactory
replayWhenNoConsumers="true"
/>
</networkBridgeFilterFactory>
</policyEntry>
<policyEntry queue="just.another.queue">
<deadLetterStrategy>
<individualDeadLetterStrategy
processExpired="true"
processNonPersistent="true"
queueSuffix=".DLQ"
useQueueForQueueMessages="true"
/>
</deadLetterStrategy>
</policyEntry>
<policyEntries>
[...]
=====
So we have some queues; queue1, queue2 and so on. They all match the
first wildcard entry in the configuration and allows messages to jump
between our network of brokers even if they already been transfered from
the reciving broker already. (replayWhenNoConsumers="true")
Just as we want and expected.
Then we have this other queue, "just.another.queue" which requires some
more specific DLQ settings. But we still want the messages to been able
to jump between the brokers even if they have the reciving broker as
origin. This doesn't work. Our hope and exceptation was that the our
more queue specific entry would inheritance from the wildcard entry and
therfor allow messages jump freely. But the messages are stuck and TRACE
gives us "Message all ready routed once through target broker [...]".
Is this the way it should work? Is there any inheritance between
policies or is it most specific wins?
--
jocar
