best way to get extensions to apply model changes immediately at runtime?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

best way to get extensions to apply model changes immediately at runtime?

John Mazzitelli
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 but I'm confused if I should override AbstractAddStepHandler.populateModel or AbstractAddStepHandler.performRuntime.

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.

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?

Thanks for any help,

John Mazz
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: best way to get extensions to apply model changes immediately at runtime?

Tomaž Cerar-2

On Thu, Apr 28, 2016 at 12:50 AM, Brian Stansberry <[hidden email]> wrote:
(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.)



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: best way to get extensions to apply model changes immediately at runtime?

Jeff Mesnil
In reply to this post by Brian Stansberry
> 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.)

Couldn’t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it’s not present?


--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: best way to get extensions to apply model changes immediately at runtime?

Brian Stansberry
On 4/28/16 7:42 AM, Jeff Mesnil wrote:

>> 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.)
>
> Couldn’t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it’s not present?
>

Not without making AD mutable, which I don't want to do, just because.

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: best way to get extensions to apply model changes immediately at runtime?

Jeff Mesnil

> On 28 Apr 2016, at 14:53, Brian Stansberry <[hidden email]> wrote:
>
> On 4/28/16 7:42 AM, Jeff Mesnil wrote:
>>> 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.)
>>
>> Couldn’t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it’s not present?
>>
>
> Not without making AD mutable, which I don't want to do, just because.

I sent my mail too fast! :) I meant on the AttributeDefinitionBuilder.

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: best way to get extensions to apply model changes immediately at runtime?

Brian Stansberry
On 4/28/16 7:54 AM, Jeff Mesnil wrote:

>
>> On 28 Apr 2016, at 14:53, Brian Stansberry <[hidden email]> wrote:
>>
>> On 4/28/16 7:42 AM, Jeff Mesnil wrote:
>>>> 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.)
>>>
>>> Couldn’t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it’s not present?
>>>
>>
>> Not without making AD mutable, which I don't want to do, just because.
>
> I sent my mail too fast! :) I meant on the AttributeDefinitionBuilder.
>

I was thinking along those lines as I responded, but I think you get a
kind of chicken/egg situation, since the OSH needs the AD in its
constructor.

Hmm, but the OSH could accept builders instead of ADs and then call
setWriteAttributeHandler(this).

This would need some trickery in the builders, e.g. avoid building the
same AD multiple times for use in the MRR, add handler and
write-attribute handler.


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev