Hi, I am not part of the specification group, but I would assume from the outside, that the current approach is to use Java 2 Collection features as much as possible leaving the old non-Collection API (Dictionary mostly) where it may not be changed without breaking backwards compatibilty.
Thus: * Configuration.getProperties() still returns Dictionary * ComponentContext.getProperties() still returns Dictionary * But: the (de)activate methods may take a Map It is therefore the task of a DS implementation to provide the correct implementation. In the Apache Felix implementation we are using a Hashtable internally, which implements both the Dictionary and the Map interfaces and thus can cope with all situations. IMHO it is good to allow a method to take a Map and this should be left. Hope this helps. Regards Felix David Wegener schrieb: > The 4.2 draft spec for Declarative Services identifies 3 ways to provide > properties to Components: Component Factory.newInstance method, > Configuration Admin Service, specified in Component description. The > ComponentFactory and ConfigurationAdminService use a Dictionary to > contain the properties. If you define properties in a Component > Description, they will be passed to the Component's activate method as a > Map. > > The activate method can take zero or more arguments. Each argument must > be of one of the following types: > • ComponentContext – The component instance will be passed the Component > Context for the component configuration. > • BundleContext – The component instance will be passed the Bundle > Context of the component's bundle. > • Map – The component instance will be passed an unmodifiable Map > containing > the component properties. > > > This creates an inconsistency since Dictionary doesn't implement the Map > interface. Implementations would have to be able to handle both a Map > and a Dictionary to allow the component to be used by each of the > different property providers. Changing the draft to look for a method > that takes a Dictionary instead of a Map would provide a consistent > interface across the different configuration options. > > Is this something that would be addressed by entering a bug report? > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
