[wildfly-dev] best way to get extensions to apply model changes immediately at runtime?

[Brian Stansberry]

On 4/27/16 4:09 PM, John Mazzitelli wrote:
> I'm in the need to support runtime changes to my subsystem extension (for example, someone should be able to use the CLI to add a child resource or change a resource's attribute and have those changes take effect immediately - i.e. support Flag.RESTART_NONE rather than Flag.RESTART_RESOURCE_SERVICES).
>
> I'm assuming I need to do this in the AddStepHandler

You use an AbstractAddStepHandler subclass for adding a child resource.

You use an AbstractWriteAttributeHandler subclass for changing an 
existing resource's attribute (i.e. the write-attribute operation.)

>but I'm confused if I should override AbstractAddStepHandler.populateModel or AbstractAddStepHandler.performRuntime.
>

Flag.RESTART_NONE and Flag.RESTART_RESOURCE_SERVICES refer to how the 
operation affects runtime services, so what's relevant there is 
performRuntime. Or in the case of AbstractWriteAttributeHandler, 
applyUpdateToRuntime.

You have an AttributeDefinition for each of your attributes. If you pass 
all of them to the AbstractAddStepHandler constructor you normally do 
not need to override populateModel as the default behavior is fine.

> Can someone fill me in on which one is recommended to be used? I'm not sure under which conditions each of those should be used and why.
>

Operations execute in stages. There are five[1], but really only two are 
relevant to people not working on the kernel code.

Stage.MODEL -- changes to the in-memory configuration model are made 
here. AbstractAddStepHandler.populateModel executes in this stage. It 
takes the parameters from the operation and sticks them in the in-memory 
configuration model.

Stage.RUNTIME -- all in-memory configuration model changes have been 
made and whatever model integrity checks we do have been performed. Now 
it's time to make changes to the running container to reflect what's in 
the configuration model. For example, add or remove MSC services. 
AbstractAddStepHandler.performRuntime is called in this stage, as is 
AbstractWriteAttributeHandler.applyUpdateToRuntime.


> The other thing is, it seems this is only for adding child resources (or removing them; I assume it is analogous for Remove Step Handlers). How do you intercept the changing of an attribute value for an existing resource, particularly if my resource extends PersistentResourceDefinition?
>

See above re AbstractWriteAttributeHandler. You'll need to write your 
own subclass which in applyUpdateToRuntime integrates with your runtime 
stuff and makes changes. For example looks up your service in MSC and 
calls a setter on the service's value object. In revertUpdateToRuntime, 
which is called in case of rollback you reverse the change.

To register your custom handler you need to override 
PersistentResourceDefinition.registerAttributes so instead of calling 
the superclass (which registers ReloadRequiredWriteAttributeHandler for 
all attributes) instead you register your handler(s).

(Tomaz, I think we need to make this write handler registration easier. 
Perhaps something like a 
PersistentResourceDefinition.getAttributeHandlers() method that returns 
a Map<String, OperationStepHandler>. And then registerAttributes uses 
the map instead of hardcoding ReloadRequiredWriteAttributeHandler. 
Default impl just fills the map values with 
ReloadRequiredWriteAttributeHandler.)


[1] 
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/OperationContext.java#L983

> Thanks for any help,
>
> John Mazz
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat