Would it be better to use a ManagedServiceFactory or ComponentFactory for this? What would be the benefit/goal of each?
My situation is this: I would like to have a single place to configure LDAP connection configuration information and have various bundles be able to use that, but if a bundle wanted to provide it's own configuration (not use the central/default) it should be able to do so. I expect the connections to come from an LDAP bundle. Suggestions? On Fri, Apr 9, 2010 at 4:41 PM, Carl Hall <[email protected]> wrote: > Thanks again for the fantastic information! It sounds like a component > factory is what I'll want to go with. I'll get to work on this and see what > I can come up with. > > > On Fri, Apr 9, 2010 at 4:22 PM, Felix Meschberger <[email protected]>wrote: > >> Hi, >> >> On 09.04.2010 22:11, Carl Hall wrote: >> > Hi Felix, Thanks for the fast response! >> > >> > If the component in question has @Reference fields in it, are they >> carried >> > over to the new instances from the factory? >> >> Yes, references are bound at component activation time just like for >> non-service factory components. >> >> > >> > Is it possible for the requesting component to send up information that >> can >> > be used to configure new instances from the factory? >> >> No, all instances of service factory components are configured the same. >> Same as all components. Actually to the service consumers service >> factory services look exactly the same as regular services. >> >> If you want your service (or component consumers) to be able to create >> specially crafted objects, you might want to consider using a component >> factory or register a factory service the consumers may call to get the >> actual object. >> >> As for component factory: you declare the component as a component >> factory by setting factory attribute to the @Component annotation. Then >> SCR registers a ComponentFactory service on behalf of the component. >> Consumers then call the newInstance(Dictionary) method on the >> ComponentFactory to actually create an instance of the real component >> which is configured according to the dictionary. >> >> But beware: consumers of the ComponentFactory components must make sure >> to call the ComponentInstance.dispose() method when done using the >> component. >> >> Regards >> Felix >> >> > >> > >> > On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <[email protected] >> >wrote: >> > >> >> Hi, >> >> >> >> On 09.04.2010 21:54, Carl Hall wrote: >> >>> When using the @Service annotation and specifying serviceFactory=true, >> >>> should I also implement the ServiceFactory interface to make sure the >> >>> (get|unget)Service methods are found or are there more annotations to >> >> mark >> >>> such methods without implementing the interface? >> >> >> >> No, if you mark a component as being a service factory component the >> >> Service Component Runtime registers a ServiceFactory implementation on >> >> behalf of the component and when a bundle requests the actual service, >> >> the runtime instantiates the component class and activates it to hand >> it >> >> out. >> >> >> >> In short, this is all take care of for the component. >> >> >> >> Regards >> >> Felix >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> >> >
