Issues with MapCompositeValue

[emuckenhuber]

Recently i noticed that the behavior of MapCompositeValue is a bit weird.

The main issue with this is that remove() does not update the MetaType. Looking into that - i don't think that the value-keys should be stored in the metaType anyway, as the metaType should be immutable.

I think we should add a keySet() to the MapCompositeValue, otherwise you could get a value when a entry was removed before.
In the meantime i worked around that and just ignore null values.
Any concerns adding this?

[ips]

I thought the MapCompositeMetaType contained a map of potential keys, for the purpose of enumerating the allowed keys and optionally specifying descriptions for those keys. If that is true, it should not be desirable to remove the corresponding item from the metatype when an item is removed from a MapCompositeValueSupport, and it should not be necessary to add a keyset() method to MapCompositeValueSupport. However, if MapCompositeMetaType doesn't enumerate all allowed keys, but just ones that have descriptions, then keySet() would need to be added, since the MapCompositeValueSupport could contain additional items that are not enumerated in the metatype.

[starksm64]

Right, the type key set is just either the allowed set of keys. Removing an item from the value should not affect what the type known as the allowed keys.

Its expected that some of the type keys would not have values. If you want to know if a CompositeValue contains a value for a given key, even if its null, the CompositeValue.containsKey(String key) method can be used.

[ips]

Scott-

I think it would be better if MapCompositeValueSupport.put() did validity checking on the key and the value like CompositeValueSupport.set() does, rather than just updating the associated MapCompositeMetaType on the fly. Ideally, I'd also make MapCompositeMetaType immutable. This would prevent management clients from altering the MetaValues or the MetaTypes in invalid ways.

I think generifying these APIs a bit more would also make them more client-friendly. For example, why not generify the item MetaType in MapCompositeMetaType and MapCompositeValueSupport to <T extends MetaType> and generify the MetaValue in ManagedProperty to <V extends MetaValue>.

Fyi, I added some Javadoc to CompositeValue, MapCompositeValueSupport, and CompositeValueSupport.

[starksm64]

Part of the problem with the MapCompositeType is that its used for Properties type of values that have no constrained set of keys. We don't know all of the allowed connection factory properties in general because it can be a function of the factory implementation. We could add a frozen notion to the MapCompositeType to allow one to restrict what can be added in the cases it is known.

We can look at generifying some of the types in the next release.