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 description like it should have no effect. On Jun 11, 2016 9:38 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote:
> 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 > >
