[ccrouch]

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.

So it looks like we really dont even have to worry about b) because the config validation in the console will prevent this situation from happening, i.e. we wont let the user specify a null value for ints or Integers.

So overall the most important thing is to have property.setRemoved() cause nothing to be persisted for the managed property, and that a default (if specified somewhere) is applied to the actual running instance. [This could just be letting the component itself choose the default, I don't think it has to come from the ManagedProperty annotation for CR1, though it would make sense in the future.] This is what I see as the core issue that needs resolving for CR1.

If we don't have this function for managedproperty's which are primitives then that's not great, but I don't necessarily see it as a blocker since there probably not that many such properties.

[starksm64]

So overall the most important thing is to have property.setRemoved() cause nothing to be persisted for the managed property, and that a default (if specified somewhere) is applied to the actual running instance. [This could just be letting the component itself choose the default, I don't think it has to come from the ManagedProperty annotation for CR1, though it would make sense in the future.] This is what I see as the core issue that needs resolving for CR1.

If we don't have this function for managedproperty's which are primitives then that's not great, but I don't necessarily see it as a blocker since there probably not that many such properties.

That a removed property has no value applied to the metadata and the metadata simply defaults to a value will apply to all managed property types, including primitives. Is that the function you are questioning?

[ccrouch]

That a removed property has no value applied to the metadata and the metadata simply defaults to a value will apply to all managed property types, including primitives. Is that the function you are questioning?

Yep, if we can get that, I think we're good for now.