[
https://issues.apache.org/jira/browse/AMQ-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15056484#comment-15056484
]
ASF subversion and git services commented on AMQ-6088:
------------------------------------------------------
Commit 9e7fae0d83c584f98e99024ba6d20e53f14b81f7 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9e7fae0 ]
https://issues.apache.org/jira/browse/AMQ-6088
The runtime plugins will now find the exact policy to update which means
that a destination can match more than one policy and the policy can
still be updated at runtime.
The java runtime broker also supports the ability to replace or add a
policy entry based on a flag on a new method call.
> 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
>
> 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)
