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 >