anonymous wrote : "ips" wrote: | | 1) Will: | | managedComponent.getProperties().remove("foo") | | be semantically equivalent to: | | managedComponent.getProperty("foo").setRemoved(true) | | ? (I think it should be) | | | Yes it should. Then it could be argued that the setRemoved/isRemoved API on ManagedProperty is not truly needed. The only advantages I see of including the API are that it's a bit easier to document Javadoc-wise, and it's easier to implement the isMandatory check I described in my previous post. anonymous wrote : The latest jboss-managed 2.1.0.CR6 simply maps MetaValues with null values onto the corresponding primitive uninitialized value when the MetaValue is unwrapped, so essentially there is no way a primitive will have a null value. I view this as akin to auto promotion of nulls so that one does not have to track whether a property is a primitive. I don't love this auto-promotion, because I think many users will still try to use simpleValue.setValue(null) to remove/unspecify that property. For non-primitive SimpleValues, this isn't a big deal, because 99% of the time it will have the same ultimate effect on the managed resource. But for primitive SimpleValues, it will end up setting the primitive to the Java init default, which will often not be the same as the underlying managed resource's default for the properties. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223074#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...