I documented my workarounds for similar use cases here http://wiki.osgi.org/wiki/Declarative_Services#Component_Factories
with actual production code here https://github.com/barchart/barchart-osgi/tree/master/factory-ca https://github.com/barchart/barchart-osgi/tree/master/factory-ds -------- Original Message -------- Subject: [DS] A new style of factory components From: David Jencks <[email protected]> To: [email protected] <[email protected]> Date: Wed 30 Oct 2013 12:47:51 PM CDT > I'm asking about this inside osgi as well. > > Factory components in DS have a number of oddities that make them unusable in > many scenarios. I'd like to suggest that some type of factory component work > very similarly to components configured from config admin with a factory PID, > but with the configuration info supplied in code to the ComponentFactory > newInstance method or a new ComponentInstance modified method. > > 1. Factory components are only registered when their references are > satisfied, based on the default target filters from xml config or properties. > (112.5.5) This might be plausible if you are not setting target filters for > references in the configuration, but if you are why would you have to wait > for _some_ possible reference targets to be registered when those are not > likely to be the ones actually bound? > > 2. The situation is worse if you want to set target filters. (112.5.5) > further explains that if the target filters are not satisfied when > newInstance is called, you get a ComponentException thrown rather than a > component waiting for the reference it needs to show up. Furthermore if any > target filter for a required reference becomes unsatisfied the component is > permanently disposed of without any notice. It is possible to track service > events yourself to keep trying to create your component but this is sort of > ridiculous. > > 2. There is no way to modify the configuration of a component instance > created from a factory component. > > What I would find useful would be a new kind of factory component where: > > 1. The ComponentFactory service is registered when the component is enabled, > irrespective of whether any references are satisifed. > > 2. Calling newInstance always creates and enables a component right away, > whether or not the references are satisfied. > > 3. The component created from newInstance persists until it is explicitly > disposed with the ComponentInstance.dispose() method or the bundle is stopped > > 4. ComponentFactory.newInstance return a subclass of ComponentInstance, say > FactoryInstance, with a modified(Dictionary) method that will update the > component properties, including (if the component is registered as a service) > the service properties, just like a CA configuration update will update a > component. I'd expect this method would not be accessible from the > ComponentContext.getComponentInstance() component instance object. > > Something would have to turn this new behavior on, either a new name for the > factory attribute (xml and annotation) or an additional attribute. > > The possibility of modifying a factory instance configuration could work for > the current style of component factory as well. > > ------------ > > My use case for this is to provide a way to process (or ignore) > Configurations for DS component similar to what is provided for > ManagedServices and ManagedServiceFactories via ConfigurationPlugins. DS > runs off of configuration events and configuration plugins are not applied to > configurations retrieved from CA, only to those pushed into MS and MSFs. In > addition I think this style of component factory would generally be much more > useful than the current factory components. > > > Thoughts? > > many thanks > david jencks > >
