Simon,
thanks for the clarification. The difference is now more clear to me.
And I suppose the value of the component factory will become even more
clear to me as soon as I stumble across some use case in my project ;-)
Regards,
Daniel
Am 18.08.2009 um 23:22 schrieb Simon J Archer:
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
----------------------
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
