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 <tb...@alumni.duke.edu> wrote: > > 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
