2008/5/8 Clement Escoffier <[EMAIL PROTECTED]>: > 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:[EMAIL PROTECTED] > Envoyé : mardi 6 mai 2008 16:49 > À : [email protected] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Stuart
