Hi Danail, The servicefactory attribute is in fact present to support the ServiceFactory concept. But the component does of course not implement the ServiceFactory interface and needs another means of getting at the bundle, requesting the service.
This information is provided by the ComponentContext.getUsingBundle() method which returns the using bundle. The ComponentContext in turn is provided to the (optional) activate method of the component. See Section 112.11.3.7 of the Compendium specification for the description of the method. Hope this helps. Regards Felix Danail Nachev schrieb: > Hey guys, > > While I was wandering in the DS specification, I reached the service > factory section: > > ... > * servicefactory – Controls whether the service uses the ServiceFactory > concept of the OSGi Framework. The default value is false. If > servicefactory is set to true, a different component configuration is > created, activated and its component instance returned as the service > object for each distinct bundle that requests the service. Each of these > component configurations has the same component properties. Otherwise, > the same component instance from the single component configuration > is returned as the service object for all bundles that request the > service. > ... > > So, if the attribute is specified, component instances will be created > for each bundle, which requests the service, but these component > instances will be absolutely the same, they are not distinguishable, > just have different object identities. How this can serve any purpose, > if the developer cannot distinguish the instances? > > If it was normal ServiceFactory, the bundle, which requested the > service, is passed to the service and the logic can use it for some > purpose (for example, preference implementation use the bundle id to > separate the preference of one bundle from the other). > > My suggestion is to add additional property in the components > properties: bundle.id, which is set if the component is ServiceFactory > and contains the value of the bundle, which requested the service. > > I'll convert this to bug, if we all agree that I haven't missed something:) > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
