Model attributes and default values

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

Model attributes and default values

Alessio Soldano
Hi,
QA has been testing various value transitions on the attributes in the
webservices subsystem of the model and found something unexpected for
attributes with default values. I had a look and found that when running
the following commands:

/subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
reload
/subsystem=webservices:undefine-attribute(name=modify-wsdl-address)

for the last command the
WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed
true as resolvedValue and undefined as currentValue. The resolvedValue
being true is because of the default value for that attribute being
true, but is it correct to get undefined as currentValue in that case?
Do I have to manually figure out there's a default value for the
attribute and hence decide nothing was changed if currentValue is
undefined and resolvedValue equals default value... or is there's a
specific way to deal with this scenario?

Thanks
Alessio

--
Alessio Soldano
Web Service Lead, JBoss

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

Re: Model attributes and default values

Brian Stansberry
You need to handle it yourself, which admittedly isn't ideal.

It's that way because doing a full resolution of "currentValue" isn't
valid, as some factor in the resolution (say the value of a system prop)
may have changed since the time that value was last resolved in the
runtime. So you'd be finding out what it resolved to right now, not what
it was.

If currentValue is undefined you can call getAttributeDefinition to get
the AD and then get the default value via
AttributeDefinition.getDefaultValue().

If currentValue is an expression you basically have to make an
assumption that the value has changed. Which makes sense; why would a
user mutate an attribute except to make a changed?

A simple enhancement we could look at would be to encapsulate the above
in a protected method on AbstractWriteAttributeHandler.

On 5/29/15 9:02 AM, Alessio Soldano wrote:

> Hi,
> QA has been testing various value transitions on the attributes in the
> webservices subsystem of the model and found something unexpected for
> attributes with default values. I had a look and found that when running
> the following commands:
>
> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
> reload
> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
>
> for the last command the
> WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed
> true as resolvedValue and undefined as currentValue. The resolvedValue
> being true is because of the default value for that attribute being
> true, but is it correct to get undefined as currentValue in that case?
> Do I have to manually figure out there's a default value for the
> attribute and hence decide nothing was changed if currentValue is
> undefined and resolvedValue equals default value... or is there's a
> specific way to deal with this scenario?
>
> Thanks
> Alessio
>


--
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: Model attributes and default values

Alessio Soldano
Thanks Brian,
will try and send a PR / let you know.

Alessio

On 01/06/15 18:07, Brian Stansberry wrote:

> You need to handle it yourself, which admittedly isn't ideal.
>
> It's that way because doing a full resolution of "currentValue" isn't
> valid, as some factor in the resolution (say the value of a system prop)
> may have changed since the time that value was last resolved in the
> runtime. So you'd be finding out what it resolved to right now, not what
> it was.
>
> If currentValue is undefined you can call getAttributeDefinition to get
> the AD and then get the default value via
> AttributeDefinition.getDefaultValue().
>
> If currentValue is an expression you basically have to make an
> assumption that the value has changed. Which makes sense; why would a
> user mutate an attribute except to make a changed?
>
> A simple enhancement we could look at would be to encapsulate the above
> in a protected method on AbstractWriteAttributeHandler.
>
> On 5/29/15 9:02 AM, Alessio Soldano wrote:
>> Hi,
>> QA has been testing various value transitions on the attributes in the
>> webservices subsystem of the model and found something unexpected for
>> attributes with default values. I had a look and found that when running
>> the following commands:
>>
>> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
>> reload
>> /subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
>>
>> for the last command the
>> WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed
>> true as resolvedValue and undefined as currentValue. The resolvedValue
>> being true is because of the default value for that attribute being
>> true, but is it correct to get undefined as currentValue in that case?
>> Do I have to manually figure out there's a default value for the
>> attribute and hence decide nothing was changed if currentValue is
>> undefined and resolvedValue equals default value... or is there's a
>> specific way to deal with this scenario?
>>
>> Thanks
>> Alessio
>>
>


--
Alessio Soldano
Web Service Lead, JBoss

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev