You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by jaredmac <jm...@mathworks.com> on 2008/05/06 21:14:20 UTC
Are service implementors inherently singletons?
Is it true that each component in declarative services is inherently a
singleton? That is to say, if I have something like this:
<component name="foo" immediate="true">
<implementation class="com.pkg.internal.FooImpl"/>
<service>
<provide interface="com.pkg.api.Foo"/>
</service>
</component>
then there will only ever be one instance of FooImpl? My use case is that I
want the application client to be able to say to Felix: give me a new
instance of all implementors of "Foo". In my case, Foo implementations have
state, and the application doesn't want to reuse an existing Foo.
I know that I can get multiple implementors of an interface from one bundle
to another by doing this:
<component name="foo-consumer">
...
<reference name="contributor"
interface="com.pkg.api.Foo"
bind="addFoo"
unbind="removeFoo"
cardinality="0..n"
policy="dynamic" />
</component>
but that will give me a list each of the Foo implementors, where again each
one is instantiated only one.
I guess my question could be rephrased as: can an OSGi client request that a
new instance of a particular service provider be created, as opposed to
getting the existing instance?
Thanks,
Jared
--
View this message in context: http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17090261.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Are service implementors inherently singletons?
Posted by Stuart McCulloch <st...@jayway.net>.
2008/5/7 Stuart McCulloch <st...@jayway.net>:
> 2008/5/7 jaredmac <jm...@mathworks.com>:
>
> >
> >
> > Felix Meschberger-2 wrote:
> > >
> > > Not as per the OSGi framework specification. You might of course - as
> > I
> > > said above - create a FooFactory and register that factory as a
> > service.
> > > Your application would then get the FooFactory service and ask that
> > > FooFactory for Foo instances.
> > >
> > > Hope this helps.
> > >
> >
> > Great, thank you - that does help. A FooFactory is exactly where I was
> > headed, and I wanted to make sure that I wasn't creating extra work for
> > myself if there were some factory-like capabilities built in to OSGi.
> >
>
> Actually there are factory concepts built into OSGi which let you create
> new service instances on demand, and tailor them per client request...
>
> For plain services you'd need to implement the ServiceFactory API
> (see section 5.6, page 117 of the core spec)
>
> For configurable services you'd use ManagedServiceFactory instead
> (see section 104.6, page 77 of the compendium spec)
>
> For component services, ie. DS, you would use a factory component
> (see section 112.2.4, page 286 of the compendium spec) - the SCR
> bundle will register a ComponentFactory service using the factory id
> on behalf of the providing bundle, which client bundles can then use
> to create component instances (see the newInstance method)
>
forgot to mention that you can also set the 'servicefactory=true' attribute
on the component service declaration, and you'll get a new component
configuration created and activated for each requesting bundle.
(see 112.4.6, page 296 of the compendium spec)
this is simpler than using a component factory, because clients don't
have to use newInstance to create component instances - but it does
mean you'll only get one instance per requesting client bundle, while
with a component factory clients could decide to create any number...
HTH - the core and compendium specs have better explanations :)
>
> http://www.osgi.org/Specifications/HomePage
>
> Thanks again,
> > Jared
> > --
> > View this message in context:
> > http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html
> > Sent from the Apache Felix - Users mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> Cheers, Stuart
--
Cheers, Stuart
Re: Are service implementors inherently singletons?
Posted by Felix Meschberger <fm...@gmail.com>.
HI,
Am Mittwoch, den 07.05.2008, 14:51 +0800 schrieb Stuart McCulloch:
> 2008/5/7 Felix Meschberger <fm...@gmail.com>:
>
> > Hi,
> >
> > Am Mittwoch, den 07.05.2008, 12:29 +0800 schrieb Stuart McCulloch:
> > True, when using SCR to define a ComponentFactory, the SCR will create
> > an instance of the component (and register as a service if configured
> > so) for each configuration received from the Configuration Admin. Still,
> > this mechanism is driven by Configuration Objects and not by direct
> > application control.
> >
>
> actually my reading of the spec suggests that anything can get the
> component factory service registered by SCR and use it to create
> new component instances - I can't see where it says this is only for
> the config admin service...
Outsch ! Yes, you are of course right. Sorry for bringing in my
confusion...
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Are service implementors inherently singletons?
Posted by Stuart McCulloch <st...@jayway.net>.
2008/5/7 Felix Meschberger <fm...@gmail.com>:
> Hi,
>
> Am Mittwoch, den 07.05.2008, 12:29 +0800 schrieb Stuart McCulloch:
> > 2008/5/7 jaredmac <jm...@mathworks.com>:
> >
> > >
> > >
> > > Felix Meschberger-2 wrote:
> > > >
> > > > Not as per the OSGi framework specification. You might of course -
> as I
> > > > said above - create a FooFactory and register that factory as a
> service.
> > > > Your application would then get the FooFactory service and ask that
> > > > FooFactory for Foo instances.
> > > >
> > > > Hope this helps.
> > > >
> > >
> > > Great, thank you - that does help. A FooFactory is exactly where I was
> > > headed, and I wanted to make sure that I wasn't creating extra work
> for
> > > myself if there were some factory-like capabilities built in to OSGi.
> > >
> >
> > Actually there are factory concepts built into OSGi which let you create
> > new service instances on demand, and tailor them per client request...
> >
> > For plain services you'd need to implement the ServiceFactory API
> > (see section 5.6, page 117 of the core spec)
>
> This is probably not exactly what Jared wants: A ServiceFactory is used
> internally by the OSGi framework to create a separate Service instance
> on-demand. The ServiceFactory.getService() method is only called once
> per bundle and service factory instance. This mechanism allows to create
> separate service instances per bundle and/or to lazy instantiate the
> services.
>
my impression was Jared didn't realize OSGi had support for factories,
and imho it's better to explain the various alternatives that currently
exist
and let developers pick whichever one meets their needs - especially if
it saves them time from writing their own factory management code ;)
yes, there are trade-offs between the different types of factories - if all
you want is a customized service per-bundle (controlled by the supplier)
then service factories are good - either plain or component based.
but if you want more control then you can use the component factory
approach to allow consumers to create new instances of components
with the "newInstance" method
But the ServiceFactory provides no control to the consumer of the
> service to actually control service instance creation.
>
> >
> > For configurable services you'd use ManagedServiceFactory instead
> > (see section 104.6, page 77 of the compendium spec)
>
> A ManagedServiceFactory in fact is just a means of telling the
> Configuration Admin Service that there is a consumer for multiple
> configuration objects. What the ManagedServiceFactory does with these
> configuration objects is completely undefined.
>
I threw in the managed service factory example for
completeness - some people might find it useful
Again, this gives the application almost no control over the creation of
> Service instances. Unless the applications wants to manage the
> configurations.
>
> True, when using SCR to define a ComponentFactory, the SCR will create
> an instance of the component (and register as a service if configured
> so) for each configuration received from the Configuration Admin. Still,
> this mechanism is driven by Configuration Objects and not by direct
> application control.
>
actually my reading of the spec suggests that anything can get the
component factory service registered by SCR and use it to create
new component instances - I can't see where it says this is only for
the config admin service...
> Regards
> Felix
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Are service implementors inherently singletons?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 07.05.2008, 12:29 +0800 schrieb Stuart McCulloch:
> 2008/5/7 jaredmac <jm...@mathworks.com>:
>
> >
> >
> > Felix Meschberger-2 wrote:
> > >
> > > Not as per the OSGi framework specification. You might of course - as I
> > > said above - create a FooFactory and register that factory as a service.
> > > Your application would then get the FooFactory service and ask that
> > > FooFactory for Foo instances.
> > >
> > > Hope this helps.
> > >
> >
> > Great, thank you - that does help. A FooFactory is exactly where I was
> > headed, and I wanted to make sure that I wasn't creating extra work for
> > myself if there were some factory-like capabilities built in to OSGi.
> >
>
> Actually there are factory concepts built into OSGi which let you create
> new service instances on demand, and tailor them per client request...
>
> For plain services you'd need to implement the ServiceFactory API
> (see section 5.6, page 117 of the core spec)
This is probably not exactly what Jared wants: A ServiceFactory is used
internally by the OSGi framework to create a separate Service instance
on-demand. The ServiceFactory.getService() method is only called once
per bundle and service factory instance. This mechanism allows to create
separate service instances per bundle and/or to lazy instantiate the
services.
But the ServiceFactory provides no control to the consumer of the
service to actually control service instance creation.
>
> For configurable services you'd use ManagedServiceFactory instead
> (see section 104.6, page 77 of the compendium spec)
A ManagedServiceFactory in fact is just a means of telling the
Configuration Admin Service that there is a consumer for multiple
configuration objects. What the ManagedServiceFactory does with these
configuration objects is completely undefined.
Again, this gives the application almost no control over the creation of
Service instances. Unless the applications wants to manage the
configurations.
True, when using SCR to define a ComponentFactory, the SCR will create
an instance of the component (and register as a service if configured
so) for each configuration received from the Configuration Admin. Still,
this mechanism is driven by Configuration Objects and not by direct
application control.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Are service implementors inherently singletons?
Posted by Stuart McCulloch <st...@jayway.net>.
2008/5/7 jaredmac <jm...@mathworks.com>:
>
>
> Felix Meschberger-2 wrote:
> >
> > Not as per the OSGi framework specification. You might of course - as I
> > said above - create a FooFactory and register that factory as a service.
> > Your application would then get the FooFactory service and ask that
> > FooFactory for Foo instances.
> >
> > Hope this helps.
> >
>
> Great, thank you - that does help. A FooFactory is exactly where I was
> headed, and I wanted to make sure that I wasn't creating extra work for
> myself if there were some factory-like capabilities built in to OSGi.
>
Actually there are factory concepts built into OSGi which let you create
new service instances on demand, and tailor them per client request...
For plain services you'd need to implement the ServiceFactory API
(see section 5.6, page 117 of the core spec)
For configurable services you'd use ManagedServiceFactory instead
(see section 104.6, page 77 of the compendium spec)
For component services, ie. DS, you would use a factory component
(see section 112.2.4, page 286 of the compendium spec) - the SCR
bundle will register a ComponentFactory service using the factory id
on behalf of the providing bundle, which client bundles can then use
to create component instances (see the newInstance method)
HTH - the core and compendium specs have better explanations :)
http://www.osgi.org/Specifications/HomePage
Thanks again,
> Jared
> --
> View this message in context:
> http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Are service implementors inherently singletons?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> 2008/5/8 Richard S. Hall <he...@ungoverned.org>:
>
>
>> Stuart McCulloch wrote:
>>
>>
>>> 2008/5/8 Clement Escoffier <cl...@gmail.com>:
>>>
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> Creating instances like this have an inherent problem. You can't
>>>> assert
>>>> that
>>>> you're the only user of the created instances.
>>>>
>>>>
>>>>
>>> that's not necessarily a problem - you may actually want global access
>>> :)
>>>
>>> but it's cool that iPOJO lets you scope the service visibility while
>>> allowing
>>> you to also open it up to the global service registry, if that's what
>>> you
>>> need
>>>
>>>
>>>
>> Well, if the service is available for anyone to use, then the notion of
>> "having" your instance is essentially meaningless...particularly in the case
>> of a stateful service, as mentioned in the original message...
>>
>>
>
> but it's not necessarily an "inherent problem" if you're creating instances
> that don't have
> per-client state (there are other types of state) or you want multiple
> configurations that
> could be shared with other clients...
>
Agreed. It is only an issue if you want your own instance that no one
else can use...
> certainly you should be aware that the service is going into the global
> service registry
> and as I already said the scoping in iPOJO is neat - but I prefer people to
> know there
> are these other options (and their pros/cons)
>
Yep. This is just one potential con.
-> richard
>
>
>> -> richard
>>
>>
>>
>>>
>>>> Any consumers have access to
>>>> the service exposed by the new component instances (despite they don't
>>>> have
>>>> create the instance).
>>>>
>>>> In iPOJO, we provide a composition model doing this instantiation for
>>>> you
>>>> but asserting that only instances from the same composite have access
>>>> to
>>>> the
>>>> created instance.
>>>> For example, the following composition will create two instances from
>>>> the
>>>> specified factories. Services provided by these instances are only
>>>> available
>>>> for instances living in the composite. You could see composite as
>>>> another
>>>> service registry (in fact, it is exactly another service registry)
>>>> isolated
>>>> from the global (i.e. OSGi) service registry.
>>>>
>>>> <composite name="mycomposite">
>>>> <instance component="your-factory-name"/>
>>>> <instance component="your-second-factory-name"/>
>>>> </composite>
>>>> <instance component="mycomposite"/> <!-- just to create an instance of
>>>> the
>>>> composition -->
>>>>
>>>> The specified factories (component attribute) can be in any other
>>>> bundles.
>>>> In fact, composites goes further and you can create composites like
>>>> this :
>>>>
>>>> <composite name="mysecondcomposite">
>>>> <subservice action="instantiate"
>>>> specification="your_service_interface"/>
>>>> <subservice action="instantiate"
>>>> specification="your_second_service_interface"/>
>>>> </composite>
>>>> <instance component="mysecondcomposite"/> <!-- just to create an
>>>> instance
>>>> of
>>>> the composition -->
>>>>
>>>> In this case, the composite tracks service implementation (i.e.
>>>> component
>>>> factories) able to create instances providing the specified service
>>>> interfaces.
>>>> If these service implementations disappears or appears, the composite
>>>> will
>>>> deal with this dynamism by looking for new service implementation,
>>>> replace
>>>> the disposed instance...
>>>>
>>>> Of course, composites can import services from the global service
>>>> registry,
>>>> or can export services from the composite to OSGi.
>>>>
>>>> Clement
>>>>
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : jaredmac [mailto:jmacdona@mathworks.com]
>>>> Envoyé : mardi 6 mai 2008 16:49
>>>> À : users@felix.apache.org
>>>> Objet : Re: Are service implementors inherently singletons?
>>>>
>>>>
>>>>
>>>> Felix Meschberger-2 wrote:
>>>>
>>>>
>>>>
>>>>> Not as per the OSGi framework specification. You might of course -
>>>>> as I
>>>>> said above - create a FooFactory and register that factory as a
>>>>> service.
>>>>> Your application would then get the FooFactory service and ask that
>>>>> FooFactory for Foo instances.
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Great, thank you - that does help. A FooFactory is exactly where I was
>>>> headed, and I wanted to make sure that I wasn't creating extra work
>>>> for
>>>> myself if there were some factory-like capabilities built in to OSGi.
>>>>
>>>> Thanks again,
>>>> Jared
>>>> --
>>>> View this message in context:
>>>>
>>>>
>>>> http://www.nabble.com/Are-service-implementors-inherently-singletons--tp1709
>>>> 0261p17092093.html<
>>>> http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html
>>>>
>>>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Are service implementors inherently singletons?
Posted by Stuart McCulloch <st...@jayway.net>.
2008/5/8 Richard S. Hall <he...@ungoverned.org>:
> Stuart McCulloch wrote:
>
> > 2008/5/8 Clement Escoffier <cl...@gmail.com>:
> >
> >
> >
> > > Hi,
> > >
> > > Creating instances like this have an inherent problem. You can't
> > > assert
> > > that
> > > you're the only user of the created instances.
> > >
> > >
> >
> >
> > that's not necessarily a problem - you may actually want global access
> > :)
> >
> > but it's cool that iPOJO lets you scope the service visibility while
> > allowing
> > you to also open it up to the global service registry, if that's what
> > you
> > need
> >
> >
>
> Well, if the service is available for anyone to use, then the notion of
> "having" your instance is essentially meaningless...particularly in the case
> of a stateful service, as mentioned in the original message...
>
but it's not necessarily an "inherent problem" if you're creating instances
that don't have
per-client state (there are other types of state) or you want multiple
configurations that
could be shared with other clients...
certainly you should be aware that the service is going into the global
service registry
and as I already said the scoping in iPOJO is neat - but I prefer people to
know there
are these other options (and their pros/cons)
> -> richard
>
>
> >
> >
> > > Any consumers have access to
> > > the service exposed by the new component instances (despite they don't
> > > have
> > > create the instance).
> > >
> > > In iPOJO, we provide a composition model doing this instantiation for
> > > you
> > > but asserting that only instances from the same composite have access
> > > to
> > > the
> > > created instance.
> > > For example, the following composition will create two instances from
> > > the
> > > specified factories. Services provided by these instances are only
> > > available
> > > for instances living in the composite. You could see composite as
> > > another
> > > service registry (in fact, it is exactly another service registry)
> > > isolated
> > > from the global (i.e. OSGi) service registry.
> > >
> > > <composite name="mycomposite">
> > > <instance component="your-factory-name"/>
> > > <instance component="your-second-factory-name"/>
> > > </composite>
> > > <instance component="mycomposite"/> <!-- just to create an instance of
> > > the
> > > composition -->
> > >
> > > The specified factories (component attribute) can be in any other
> > > bundles.
> > > In fact, composites goes further and you can create composites like
> > > this :
> > >
> > > <composite name="mysecondcomposite">
> > > <subservice action="instantiate"
> > > specification="your_service_interface"/>
> > > <subservice action="instantiate"
> > > specification="your_second_service_interface"/>
> > > </composite>
> > > <instance component="mysecondcomposite"/> <!-- just to create an
> > > instance
> > > of
> > > the composition -->
> > >
> > > In this case, the composite tracks service implementation (i.e.
> > > component
> > > factories) able to create instances providing the specified service
> > > interfaces.
> > > If these service implementations disappears or appears, the composite
> > > will
> > > deal with this dynamism by looking for new service implementation,
> > > replace
> > > the disposed instance...
> > >
> > > Of course, composites can import services from the global service
> > > registry,
> > > or can export services from the composite to OSGi.
> > >
> > > Clement
> > >
> > >
> > >
> > > -----Message d'origine-----
> > > De : jaredmac [mailto:jmacdona@mathworks.com]
> > > Envoyé : mardi 6 mai 2008 16:49
> > > À : users@felix.apache.org
> > > Objet : Re: Are service implementors inherently singletons?
> > >
> > >
> > >
> > > Felix Meschberger-2 wrote:
> > >
> > >
> > > > Not as per the OSGi framework specification. You might of course -
> > > > as I
> > > > said above - create a FooFactory and register that factory as a
> > > > service.
> > > > Your application would then get the FooFactory service and ask that
> > > > FooFactory for Foo instances.
> > > >
> > > > Hope this helps.
> > > >
> > > >
> > > >
> > > Great, thank you - that does help. A FooFactory is exactly where I was
> > > headed, and I wanted to make sure that I wasn't creating extra work
> > > for
> > > myself if there were some factory-like capabilities built in to OSGi.
> > >
> > > Thanks again,
> > > Jared
> > > --
> > > View this message in context:
> > >
> > >
> > > http://www.nabble.com/Are-service-implementors-inherently-singletons--tp1709
> > > 0261p17092093.html<
> > > http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html
> > > >
> > > Sent from the Apache Felix - Users mailing list archive at Nabble.com.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Are service implementors inherently singletons?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> 2008/5/8 Clement Escoffier <cl...@gmail.com>:
>
>
>> Hi,
>>
>> Creating instances like this have an inherent problem. You can't assert
>> that
>> you're the only user of the created instances.
>>
>
>
> that's not necessarily a problem - you may actually want global access :)
>
> but it's cool that iPOJO lets you scope the service visibility while
> allowing
> you to also open it up to the global service registry, if that's what you
> need
>
Well, if the service is available for anyone to use, then the notion of
"having" your instance is essentially meaningless...particularly in the
case of a stateful service, as mentioned in the original message...
-> richard
>
>
>> Any consumers have access to
>> the service exposed by the new component instances (despite they don't
>> have
>> create the instance).
>>
>> In iPOJO, we provide a composition model doing this instantiation for you
>> but asserting that only instances from the same composite have access to
>> the
>> created instance.
>> For example, the following composition will create two instances from the
>> specified factories. Services provided by these instances are only
>> available
>> for instances living in the composite. You could see composite as another
>> service registry (in fact, it is exactly another service registry)
>> isolated
>> from the global (i.e. OSGi) service registry.
>>
>> <composite name="mycomposite">
>> <instance component="your-factory-name"/>
>> <instance component="your-second-factory-name"/>
>> </composite>
>> <instance component="mycomposite"/> <!-- just to create an instance of the
>> composition -->
>>
>> The specified factories (component attribute) can be in any other bundles.
>> In fact, composites goes further and you can create composites like this :
>>
>> <composite name="mysecondcomposite">
>> <subservice action="instantiate"
>> specification="your_service_interface"/>
>> <subservice action="instantiate"
>> specification="your_second_service_interface"/>
>> </composite>
>> <instance component="mysecondcomposite"/> <!-- just to create an instance
>> of
>> the composition -->
>>
>> In this case, the composite tracks service implementation (i.e. component
>> factories) able to create instances providing the specified service
>> interfaces.
>> If these service implementations disappears or appears, the composite will
>> deal with this dynamism by looking for new service implementation, replace
>> the disposed instance...
>>
>> Of course, composites can import services from the global service
>> registry,
>> or can export services from the composite to OSGi.
>>
>> Clement
>>
>>
>>
>> -----Message d'origine-----
>> De : jaredmac [mailto:jmacdona@mathworks.com]
>> Envoyé : mardi 6 mai 2008 16:49
>> À : users@felix.apache.org
>> Objet : Re: Are service implementors inherently singletons?
>>
>>
>>
>> Felix Meschberger-2 wrote:
>>
>>> Not as per the OSGi framework specification. You might of course - as I
>>> said above - create a FooFactory and register that factory as a service.
>>> Your application would then get the FooFactory service and ask that
>>> FooFactory for Foo instances.
>>>
>>> Hope this helps.
>>>
>>>
>> Great, thank you - that does help. A FooFactory is exactly where I was
>> headed, and I wanted to make sure that I wasn't creating extra work for
>> myself if there were some factory-like capabilities built in to OSGi.
>>
>> Thanks again,
>> Jared
>> --
>> View this message in context:
>>
>> http://www.nabble.com/Are-service-implementors-inherently-singletons--tp1709
>> 0261p17092093.html<http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html>
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Are service implementors inherently singletons?
Posted by Stuart McCulloch <st...@jayway.net>.
2008/5/8 Clement Escoffier <cl...@gmail.com>:
> Hi,
>
> Creating instances like this have an inherent problem. You can't assert
> that
> you're the only user of the created instances.
that's not necessarily a problem - you may actually want global access :)
but it's cool that iPOJO lets you scope the service visibility while
allowing
you to also open it up to the global service registry, if that's what you
need
> Any consumers have access to
> the service exposed by the new component instances (despite they don't
> have
> create the instance).
>
> In iPOJO, we provide a composition model doing this instantiation for you
> but asserting that only instances from the same composite have access to
> the
> created instance.
> For example, the following composition will create two instances from the
> specified factories. Services provided by these instances are only
> available
> for instances living in the composite. You could see composite as another
> service registry (in fact, it is exactly another service registry)
> isolated
> from the global (i.e. OSGi) service registry.
>
> <composite name="mycomposite">
> <instance component="your-factory-name"/>
> <instance component="your-second-factory-name"/>
> </composite>
> <instance component="mycomposite"/> <!-- just to create an instance of the
> composition -->
>
> The specified factories (component attribute) can be in any other bundles.
> In fact, composites goes further and you can create composites like this :
>
> <composite name="mysecondcomposite">
> <subservice action="instantiate"
> specification="your_service_interface"/>
> <subservice action="instantiate"
> specification="your_second_service_interface"/>
> </composite>
> <instance component="mysecondcomposite"/> <!-- just to create an instance
> of
> the composition -->
>
> In this case, the composite tracks service implementation (i.e. component
> factories) able to create instances providing the specified service
> interfaces.
> If these service implementations disappears or appears, the composite will
> deal with this dynamism by looking for new service implementation, replace
> the disposed instance...
>
> Of course, composites can import services from the global service
> registry,
> or can export services from the composite to OSGi.
>
> Clement
>
>
>
> -----Message d'origine-----
> De : jaredmac [mailto:jmacdona@mathworks.com]
> Envoyé : mardi 6 mai 2008 16:49
> À : users@felix.apache.org
> Objet : Re: Are service implementors inherently singletons?
>
>
>
> Felix Meschberger-2 wrote:
> >
> > Not as per the OSGi framework specification. You might of course - as I
> > said above - create a FooFactory and register that factory as a service.
> > Your application would then get the FooFactory service and ask that
> > FooFactory for Foo instances.
> >
> > Hope this helps.
> >
>
> Great, thank you - that does help. A FooFactory is exactly where I was
> headed, and I wanted to make sure that I wasn't creating extra work for
> myself if there were some factory-like capabilities built in to OSGi.
>
> Thanks again,
> Jared
> --
> View this message in context:
>
> http://www.nabble.com/Are-service-implementors-inherently-singletons--tp1709
> 0261p17092093.html<http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html>
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
RE: Are service implementors inherently singletons?
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
Creating instances like this have an inherent problem. You can't assert that
you're the only user of the created instances. Any consumers have access to
the service exposed by the new component instances (despite they dont have
create the instance).
In iPOJO, we provide a composition model doing this instantiation for you
but asserting that only instances from the same composite have access to the
created instance.
For example, the following composition will create two instances from the
specified factories. Services provided by these instances are only available
for instances living in the composite. You could see composite as another
service registry (in fact, it is exactly another service registry) isolated
from the global (i.e. OSGi) service registry.
<composite name="mycomposite">
<instance component="your-factory-name"/>
<instance component="your-second-factory-name"/>
</composite>
<instance component="mycomposite"/> <!-- just to create an instance of the
composition -->
The specified factories (component attribute) can be in any other bundles.
In fact, composites goes further and you can create composites like this :
<composite name="mysecondcomposite">
<subservice action="instantiate"
specification="your_service_interface"/>
<subservice action="instantiate"
specification="your_second_service_interface"/>
</composite>
<instance component="mysecondcomposite"/> <!-- just to create an instance of
the composition -->
In this case, the composite tracks service implementation (i.e. component
factories) able to create instances providing the specified service
interfaces.
If these service implementations disappears or appears, the composite will
deal with this dynamism by looking for new service implementation, replace
the disposed instance...
Of course, composites can import services from the global service registry,
or can export services from the composite to OSGi.
Clement
-----Message d'origine-----
De : jaredmac [mailto:jmacdona@mathworks.com]
Envoyé : mardi 6 mai 2008 16:49
À : users@felix.apache.org
Objet : Re: Are service implementors inherently singletons?
Felix Meschberger-2 wrote:
>
> Not as per the OSGi framework specification. You might of course - as I
> said above - create a FooFactory and register that factory as a service.
> Your application would then get the FooFactory service and ask that
> FooFactory for Foo instances.
>
> Hope this helps.
>
Great, thank you - that does help. A FooFactory is exactly where I was
headed, and I wanted to make sure that I wasn't creating extra work for
myself if there were some factory-like capabilities built in to OSGi.
Thanks again,
Jared
--
View this message in context:
http://www.nabble.com/Are-service-implementors-inherently-singletons--tp1709
0261p17092093.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Are service implementors inherently singletons?
Posted by jaredmac <jm...@mathworks.com>.
Felix Meschberger-2 wrote:
>
> Not as per the OSGi framework specification. You might of course - as I
> said above - create a FooFactory and register that factory as a service.
> Your application would then get the FooFactory service and ask that
> FooFactory for Foo instances.
>
> Hope this helps.
>
Great, thank you - that does help. A FooFactory is exactly where I was
headed, and I wanted to make sure that I wasn't creating extra work for
myself if there were some factory-like capabilities built in to OSGi.
Thanks again,
Jared
--
View this message in context: http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Are service implementors inherently singletons?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 06.05.2008, 12:14 -0700 schrieb jaredmac:
> Is it true that each component in declarative services is inherently a
> singleton? That is to say, if I have something like this:
>
> <component name="foo" immediate="true">
> <implementation class="com.pkg.internal.FooImpl"/>
> <service>
> <provide interface="com.pkg.api.Foo"/>
> </service>
> </component>
>
> then there will only ever be one instance of FooImpl?
For this exact declaration, there will only be a single instance created
(and registered as a service) when the containing bundle is started.
When the containing bundle is stopped, the service is unregistered and
the instance dropped.
When the bundle is started again, a new instance is created and
registered as a service.
So, it is actually more precise to say, that at any moment in time,
there is only a single instance of the component existing, which is also
registered as Foo service.
> My use case is that I
> want the application client to be able to say to Felix: give me a new
> instance of all implementors of "Foo". In my case, Foo implementations have
> state, and the application doesn't want to reuse an existing Foo.
What you want is probably a Foo factory: Your application asks the Foo
factory for instances of the Foo interface implementations.
>
> I know that I can get multiple implementors of an interface from one bundle
> to another by doing this:
>
> <component name="foo-consumer">
> ...
> <reference name="contributor"
> interface="com.pkg.api.Foo"
> bind="addFoo"
> unbind="removeFoo"
> cardinality="0..n"
> policy="dynamic" />
> </component>
>
> but that will give me a list each of the Foo implementors, where again each
> one is instantiated only one.
Yes, the reference element just instructs the Declarative Services
runtime to provide registered services to the foo-consumer. This is
exactly the same as accessing these services through the BundleContext.
>
> I guess my question could be rephrased as: can an OSGi client request that a
> new instance of a particular service provider be created, as opposed to
> getting the existing instance?
Not as per the OSGi framework specification. You might of course - as I
said above - create a FooFactory and register that factory as a service.
Your application would then get the FooFactory service and ask that
FooFactory for Foo instances.
Hope this helps.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org