OSGi is moving to use collection types like Map were possible. This is why Map is used in the constructor arguments. For Framework 2.0 we plan to abandon Dictionary entirely. But for DS in 4.2, the DS impl will need to handle the Dictionary to Map mapping :-)
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
Office: +1 386 848 1781 Mobile: +1 386 848 3788
----- Original Message -----
From: David Wegener [[email protected]]
Sent: 06/18/2009 09:05 PM EST
To: [email protected]
Subject: [osgi-dev] 4.2 Draft Declarative Service properties aren't
consistent handled
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
