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