will try and send a PR / let you know.
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
If currentValue is undefined you can call getAttributeDefinition to get
the AD and then get the default value via
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:
> 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:
> 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?
Web Service Lead, JBoss