2008/5/7 Felix Meschberger <[EMAIL PROTECTED]>: > Hi, > > Am Mittwoch, den 07.05.2008, 12:29 +0800 schrieb Stuart McCulloch: > > 2008/5/7 jaredmac <[EMAIL PROTECTED]>: > > > > > > > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Stuart
