Right, there is no inheritance between policies or merging semantics as Tim
pointed out. So if you define a new policy then you need to re-apply all
the settings you want to the new policy as well.
On Fri, Jun 17, 2016 at 9:09 AM, Johan Carlquist wrote:
> Thanks for your reply.
>
> It had been
Thanks for your reply.
It had been nice to avoid dublicated queue configuration so we will look
in to make an JIRA enhancement request for this later this
summer.
--
jocar
> On 11 Jun 2016, at 17:43, Tim Bain wrote:
>
> Sorry, I just re-read your description of the behavior and clearly it's n
Sorry, I just re-read your description of the behavior and clearly it's not
first-match as I had believed. But I still believe that there are no
merging semantics available, so the solutions I described still apply
except for the statement that you need to reorder the list, which sounds
from your
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
Hi!
Our config:
=
[...]
[...]
=
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 tra
