[jboss-jira] [JBoss JIRA] (WFCORE-1092) ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
Brian Stansberry (JIRA)
issues at jboss.org
Tue Nov 3 17:42:00 EST 2015
[ https://issues.jboss.org/browse/WFCORE-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Stansberry updated WFCORE-1092:
-------------------------------------
Description:
ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the
was:
ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
> ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1092
> URL: https://issues.jboss.org/browse/WFCORE-1092
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Final
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha1
>
>
> ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
> A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list