[
https://issues.apache.org/jira/browse/AMQ-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon resolved AMQ-6088.
-----------------------------------------
Resolution: Fixed
Fix Version/s: 5.14.0
5.13.1
A policy can now be modified even if it matches more than one destination
because the policy will only be applied to the correct destination(s) during
update. This includes the case of a new policy as well. This applies to both
the Java and XML runtime plugins.
Also, there's a new option in the Java plugin to create or replace (based on a
flag) a policy entry. For the replace case, that is useful if someone wants to
update a policy without looking up the existing one first, which is required in
the current version.
> Runtime configuration does not properly apply policy updates
> ------------------------------------------------------------
>
> Key: AMQ-6088
> URL: https://issues.apache.org/jira/browse/AMQ-6088
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.13.0
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
>
> There is 1 bug and 1 improvement with policy modification at runtime with
> both the XML runtime broker and Java runtime broker.
> For the bug portion, when a new policy is added there is no check to see if
> there are any more specific policies that should be used. So if a policy
> called "queue.test.child.>" exists, and then a new policy for "queue.test.>"
> is added, this will update destinations that match the more specific policy
> and it shouldn't. There is a check for this for modification (as seen below)
> but not on adding a new policy.
> For the improvement, when modifying a policy entry, an entry can only be
> modified if there are no children entries. This is a problem because if two
> policies exist, say for "queue.test.>" and "queue.test.child.>", we can not
> modify "queue.test.>" because there is logic to prevent this. This is done
> to prevent reapplying changes to destinations that might be affected by
> "queue.test.child.>". (which breaks on an add)
> However, with the use of the policy map we should be able to update any
> policy and figure out which specific destinations because we can look up
> whether or not the policy being updated should be applied to the destination.
> So this limitation should be removed and the proper logic should be applied
> for both adding and updating policies.
> This should be merged into 5.13.1 because it's a bug fix and improvement to
> how policies are applied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
