Hi Andrei, I like your description of how config admin relates to DS, this is a topic that is rarely explained so well.
I don't see the workarounds you mention, could you be more specific? I'm also not sure what the factory-ds code is supposed to demonstrate. many thanks, david jencks On Oct 30, 2013, at 12:32 PM, Andrei Pozolotin <[email protected]> wrote: > 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 >> >> >
