Re: [wildfly-dev] Model attributes and default values
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