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

On 4/27/16 4:09 PM, John Mazzitelli wrote: 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.) 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. 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. 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/j... -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat