[jboss-as7-dev] Management proposal for attribute mutability

[Brian Stansberry]

On 8/22/11 1:42 PM, Jason T. Greene wrote:
> 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.
>

Sure, what you propose is the right solution for only bouncing a 
datasource. But, if the operation has "impact-services" --> false, I'm 
just saying the handler should not "return an error" (i.e. throw an 
exception or use context.getFailureDescription().set("blah blah")). It 
should properly inform the context that restart or reload is required.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat