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 <jo...@su.se> wrote: > 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 > >
