BJ Hargrave <[EMAIL PROTECTED]> writes: > In general, for a given PID, it is either a "normal" configuration > or a factory configuration. It wont change.
Does that mean that if some bundle creates a non-factory Configuration and binds it to a PID, that PID can no longer (or never again) be used as a PID for a ManagedServiceFactory? Again, it seems like an innocent mistake or sabotage can ruin the operation of a factory by prematurely "stealing" its PID. > Well CM will not allow both normal and factory configuration for a > given PID. So I think there should be no problem. Yes, provided the /first/ use of the PID is for a factory, right? > You will be able to use DS to handle the factory config case and SCR > will activate component instances one for configuration. Does this mean that my component under control of DS does not need to declare anything CM-related, such as implementing ManagedServiceFactory, or advertising some property marking it as a factory? A plain old component will be instantiated many times by DS acting as a ManagedServiceFactory on my behalf? > 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). I see. Are these properties then available to the component by way of ComponentContext.getProperties()? I'm asking because if I don't implement ManagedServiceFactory.updated(String, Dictionary) myself, how else will my components have access to the Configuration to which they're bound? > You are making sense... :-) Finally, some good news. Thanks for your patience. -- Steven E. Harris _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
