On 8/22/11 1:26 PM, Brian Stansberry wrote:
On 8/2/11 4:22 PM, Jason T. Greene wrote:
> Currently we have way too many read only attributes in our management
> model. This makes life harder for the management tools and/or makes the
> resulting UI a bit unwieldy.
>
> In some cases this is just because we haven't polished subsystem
> management (PLEASE all subsystem authors look at this!). In other cases
> though it's intentional because it is either difficult or currently
> impossible to make hot changes to a particular attribute. This should be
> exceedingly rare. Users love hot updates, and it's a competitive
> advantage. So first we should strive to make it hot in the first place.
>
> However in the case that the change is not hot, and a server reboot is
> too aggressive, we should still supporting making the changes by
> bouncing all services involved. After some debate on IRC we finally
> arrived at what is IMO a really good option for this problem:
>
> write-attribute (impact-services=true|false)
>
> The operation handler on such a non-hot attribute would then return an
> error
A handler should not return an error if a change cannot be applied to
the runtime. An OperationStepHandler should use the relevant API on the
OperationContext. E.g. for a handler registered for Stage.RUNTIME:
@Override
public void execute(OperationContext context, ModelNode operation) {
context.runtimeUpdateSkipped();
context.reloadRequired(); // or context.restartRequired();
if (context.completeStep() ==
OperationContext.ResultAction.ROLLBACK)
{
context.revertReloadRequired();
// or context.revertRestartRequired();
}
}
Well in my above comment I was referring to a problem where a full
server reload and/or restart is too aggressive (i.e. why bounce the web
server when all you want to do is bounce a datasource). So the issue is
that these attributes don't fit that problem.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat