[
https://issues.apache.org/jira/browse/QPID-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7934:
-----------------------------
Description:
A recovered {{RuleBasedVirtualHostAccessControlProvider}} doesn’t tell its
virtualhost about changes to itself, so the virtualhost doesn’t react to
changes in its state (i.e. the rule-set). This issue exists on the normal
Broker start-up path. It means that if the user attempts to change a rule-set
the changes are not applied.
If a new RuleBasedVirtualHostAccessControlProvider is added, changes made to it
are reported properly to the VirtualHost. (This is why
{{VirtualHostAccessControlProviderRestTest}} does not fail).
The issue is that {{AbstractVirtualHost#postResolveChildren}} fails to add
state listeners to existing {{VirtualHostAccessControlProviders}}. The same
issue applies on the virtualhost restart path (much like QPID-7933).
There is a second problem that lies behind the first. If you fix
#postResolveChildren to install the listener on the existing VHACP, you find
that the VH still fails to update its ACL controller state probably after
changes to the provider. This problem is that
{{AbstractVirtualHost#updateAccessControl}} gets called (by the super call at
line AbstractCommonRuleBasedAccessControlProvider.java:70) before
{{AbstractLegacyAccessControlProvider#recreateAccessController}} on the
following line so the VH continues to stale a stale controller.
was:
A recovered {{RuleBasedVirtualHostAccessControlProvider}} doesn’t tell its
virtualhost about changes to itself, so the virtualhost doesn’t react to
changes in its state (i.e. the rule-set). This issue exists on the normal
Broker start-up path. It means that if the user attempts to change a rule-set
the changes are not applied.
If a new RuleBasedVirtualHostAccessControlProvider is added, changes made to it
are reported properly to the VirtualHost. (This is why
VirtualHostAccessControlProviderRestTest does not fail).
The issue is that {{AbstractVirtualHost#postResolveChildren}} fails to add
state listeners to existing {{VirtualHostAccessControlProviders}}. The same
issue applies on the virtualhost restart path (much like QPID-7933).
There is a second problem that lies behind the first. If you fix
#postResolveChildren to install the listener on the existing VHACP, you find
that the VH still fails to update its ACL controller state probably after
changes to the provider. This problem is that
{{AbstractVirtualHost#updateAccessControl}} gets called (by the super call at
line AbstractCommonRuleBasedAccessControlProvider.java:70) before
{{AbstractLegacyAccessControlProvider#recreateAccessController}} on the
following line so the VH continues to stale a stale controller.
> [Java Broker] A recovered RuleBasedVirtualHostAccessControlProvider doesn’t
> tell the virtualhost about updates to its rule-state
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7934
> URL: https://issues.apache.org/jira/browse/QPID-7934
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Keith Wall
> Priority: Minor
>
> A recovered {{RuleBasedVirtualHostAccessControlProvider}} doesn’t tell its
> virtualhost about changes to itself, so the virtualhost doesn’t react to
> changes in its state (i.e. the rule-set). This issue exists on the normal
> Broker start-up path. It means that if the user attempts to change a
> rule-set the changes are not applied.
> If a new RuleBasedVirtualHostAccessControlProvider is added, changes made to
> it are reported properly to the VirtualHost. (This is why
> {{VirtualHostAccessControlProviderRestTest}} does not fail).
> The issue is that {{AbstractVirtualHost#postResolveChildren}} fails to add
> state listeners to existing {{VirtualHostAccessControlProviders}}. The same
> issue applies on the virtualhost restart path (much like QPID-7933).
> There is a second problem that lies behind the first. If you fix
> #postResolveChildren to install the listener on the existing VHACP, you find
> that the VH still fails to update its ACL controller state probably after
> changes to the provider. This problem is that
> {{AbstractVirtualHost#updateAccessControl}} gets called (by the super call at
> line AbstractCommonRuleBasedAccessControlProvider.java:70) before
> {{AbstractLegacyAccessControlProvider#recreateAccessController}} on the
> following line so the VH continues to stale a stale controller.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
