Hi Steven - Just as a heads-up...
I'm not sure if you're using the Equinox implementation of DS or not (if you're not then you can stop reading this now :), but I don't think that it currently supports the ManagedServiceFactory scenario as described in the DS spec. More at https://bugs.eclipse.org/bugs/show_bug.cgi?id=163705 I noticed this behavior when I was doing some DeclarativeServices and ConfigurationAdmin work a while back. - Ben PS. Sorry for the Equinox-specific nature of this post, but I think it's relevant enough to include here. On 2/28/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote on 02/28/2007 02:25:27 PM: > In Section 112.7 of the DS Specification, "Deployment" we find the > following paragraph: > > ,---- > | The name of the component is used as the key for obtaining additional > | component properties from Configuration Admin. The following > | situations can arise: > | > | o No Configuration -- If there is no Configuration with a PID or > | factory PID equal to the component name, then component > | configurations will not obtain component properties from > | Configuration Admin. Only component properties specified in the > | component description or via the ComponentFactory.newInstance method > | will be used. > | > | o Single Configuration -- If there exists a Configuration with a PID > | equal to the component name, then component configurations will > | obtain additional component properties from Configuration > | Admin. This is the ManagedService situation. > | > | o Factory Configuration -- If a factory PID exists, with zero or more > | Configurations, that is equal to the component name, then for each > | Configuration, a component configuration must be created that will > | obtain additional component properties from Configuration > | Admin. This is the ManagedServiceFactory situation. > `---- > > I'm interested in getting the "Factory Configuration" mode to work, > but by my reading here, it's not clear /when/ the given mode is > selected, as the selection is bade on which Configurations exist at > some point in time. > > Is the existence of Configurations examined at the time the component > is activated? What happens if at first there is one Configuration with > a PID matching the component name, but then later several > Configurations get created against a matching factory PID? Or, > consider the situation in reverse, with a factory PID existing and > single Configuration coming along using the same PID? In general, for a given PID, it is either a "normal" configuration or a factory configuration. It wont change. A given configuration target either has a single set of configuration properties (e.g. the number of threads in a thread pool) or it will have multiple sets (e.g. the configurations for the ports on which an http server will listen). So when SCR is trying to locate configuration information for a component, it will use the ConfigAdmin.listConfigurations api using the PID in the filter. It will either find a no configuration information, a single "normal" configuration, or one or more "factory" configurations. > > I'm trying to figure out whether DS will automate the implementation > of a ManagedServiceFactory on my behalf. If so, will this automation > be sabotaged if someone or something accidentally creates a "single > Configuration" as described above? What if the factory PID-bound > Configurations get created after the component's mode has been > determined? Well CM will not allow both normal and factory configuration for a given PID. So I think there should be no problem. You will be able to use DS to handle the factory config case and SCR will activate component instances one for configuration. SCR will need to look for configuration information to determine of the component can be "satisfied" (section 112.5.2) since the configuration value can influnce this (for example the target property see 112.6). > > And if I'm not making any sense, then several days worth of > (re)reading the CM and DS specifications was clearly insufficient. You are making sense... :-) > > -- > Steven E. Harris > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev 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 _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
