I knew I was missing something:) BR, -- Danail Nachev Senior Software Engineer/Development Tools ProSyst Labs EOOD ------------------------------------------------- stay in touch with your product. -------------------------------------------------
Felix Meschberger wrote: > 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 > > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
