I tend to think of a service factory is an implementation detail of the bundle/component since the bundles that reference the service do not know (or care) that they are getting their own unique instance of the service. This can be valuable, for example, if each service needs to maintain state about the bundle that's using it. When using a service factory all instances are born equal. The OSGi framework takes care of creating a unique instance for each bundle -- there is nothing further that you, the bundle developer, can do.
A DS component factory, on the other hand, is designed to allow many DS components to be created/manufactured with possibly different initial property values. But in this case the creation of the DS components is done at runtime by some bundle, written by you, whose job is to do just that... bundles such as this are configuring the runtime based on some rules. Remember we're creating DS components here, not services, and a DS component may or may not provide services. A DS component might be "immediate" and start doing work on something upon creation, or it might provide a service that is used by some other bundle, but that's not important. I hope this helps. Simon From: Daniel Bimschas <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 08/18/2009 03:08 PM Subject: Re: [osgi-dev] Declarative Services and Component Factories Sent by: [email protected] I'm so happy to hear that, as I was already beginning to feel stupid ;-) Thank your for the information! Taking a step back, I think this bug was the only reason I tried using the component factory before in a way that should do what service factories do :-) But now, I still wonder what's the practical and conceptional difference of component vs. service factories. Can somebody help me on that? Kind Regards, Daniel Am 18.08.2009 um 15:11 schrieb Stoyan Boshev: > Hi Daniel, > > This is a known bug, but it was already fixed (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=285464) > . > The fix exists in the last Eclipse 3.6 integration build and > 3.5.1RC1 build. > > Stoyan > > Daniel Bimschas wrote: >> Just tried using the service factory mechanism. The result is the >> following error message: >> "ComponentReference.bind(): service reference >> {org.osgi.service.log.LogService, >> org.eclipse.equinox.log.ExtendedLogService}={service.id=30} is >> already bound to another instance: ..." >> The reference here is used for getting the OSGi LogService in the >> Logger service that is now declared with servicefactory="true" like >> this: >> <reference name="logService" >> interface="org.osgi.service.log.LogService" cardinality="1..1" >> policy="static" bind="bindLogService" unbind="unbindLogService"/> >> Can you also help me with that? It seems there's only one reference >> allowed for this component. Didn't find anything about that in >> 112.3... >> Thanks, Daniel >> Am 18.08.2009 um 03:54 schrieb Simon J Archer: >>> >>> Daniel >>> >>> >>Consider a logging service that wants to provide a different >>> logger >>> >>instance for every bundle requesting a logger. >>> >>> If all you want to do is provide a unique instance of the Logger >>> service to each bundle that requires one, consider using a service >>> factory rather than a component factory: >>> >>> <service servicefactory="true"> >>> <provide interface="the.package.Logger"/> >>> </service> >>> >>> // 112.4.6 >>> "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." >>> >>> The bundle that references the Logger service does not know that >>> its getting a unique instance. >>> >>> I hope this help. >>> >>> Simon >>> >>> >>> From: >>> Daniel Bimschas <[email protected]> >>> To: >>> [email protected] >>> Date: >>> 08/17/2009 04:09 PM >>> Subject: >>> [osgi-dev] Declarative Services and Component Factories >>> Sent by: >>> [email protected] >>> >>> >>> >>> >>> Hi, >>> >>> I'm using the OSGi DS spec, respectively the SCR runtime, to declare >>> my components and their required references. Now I have the >>> following >>> use-case for which I'm unsure about on how to implement it: >>> >>> Consider a logging service that want's to provide a different logger >>> instance for every bundle requesting a logger. Therefore I've >>> implemented a service implement, class Logger and declared it the >>> following way: >>> >>> <scr:component enabled="true" name="LoggerService" >>> factory="LoggerServiceFactory"> >>> <implementation class="the.package.impl.LoggerImpl"/> >>> <service> >>> <provide interface="the.package.Logger"/> >>> </service> >>> </scr:component> >>> >>> So now, the only way I found out on how to get a reference to a >>> LoggerService instance is to get a reference to the ComponentFactory >>> "LoggerServiceFactory" and programmatically calling >>> newInstance(Dictionary) on it. >>> >>> I wonder if there's no "more declarative" way for referencing a >>> component produced by the declared component factory. Something like >>> this would be straightforward in my opinion, allowing to declare >>> references with passing configuration: >>> >>> <reference name="log" interface="the.package.Logger" >>> cardinality="1..1" policy="static" bind="bindLog" >>> unbind="unbindLog"> >>> <property key="loggername" value="The loggers instance name" /> >>> </reference> >>> >>> Thanks for your help or clarification in advance! >>> >>> Kind regards, >>> Daniel Bimschas >>> _______________________________________________ >>> 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 >> ---------------------- >> Daniel Bimschas >> Fleischhauer Straße 45 >> 23552 Lübeck >> [email protected] >> ---------------------- >> _______________________________________________ >> 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 > ---------------------- Daniel Bimschas Fleischhauer Straße 45 23552 Lübeck [email protected] ---------------------- _______________________________________________ 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
