"charles.crouch(a)jboss.com" wrote :
| I think this is fine, as long as we can support the following scenarios:
|
| a) ManagedProperty wraps an int and the user does not want to give it a value (i.e.
he's happy with whatever value the server default is e.g. 0, 20, 100).
| The user sets unset=true in the console and then the plugin calls
property.setRemoved(true).
|
| b) ManagedProperty wraps an int and the user specifies no value.
| The user sets unset=false in the console, but leaves the value blank. The plugin will
do property.setValue(null) and PS will initialize the underlying value to 0, which is the
value the console will see next time it queries the PS.
| I see this as just the fallout from using int's in a components' managed api,
if the component developer wants to support letting the user specify null, then they
should use an Integer.
|
Agreed. So the only issue is whether we make the default value part of the management api
on the ManagedProperty so that its both documented what the defaults are, and there is
consistent behavior between a primitive with an initializer (int x = 1) and
@ManagmentProperty(defaultValue="1"). I don't see I'll have that working
by tomorrow, so we'll have to talk about if this is worthwhile pursuing for CR1 vs
other issues tomorrow.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223082#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...