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,
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, 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
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
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
Thanks for any help,
wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat