(potential confusion warning, note that factory configurations are from CA, when you use a createFactroyConfiguration method, whereas factory components are from DS where you specify in the xml descriptor that you have a factory component and you'll use ComponentFactory.newInstance to get actual instance(s)).
I recently proposed in Felix DS allowing factory configurations (factory pids) to create instances of a factory component, each of which would be an independently configured ComponentFactory which could be used to create actual instances with the newInstance method; along with this is a way to add more service properties to the ComponentFactory services so you can distinguish them from each other. My main motivation for adding these is that I don't see the point in ruling out one combination of features that otherwise makes sense, has very little implementation overhead, makes the model more logically complete, and might be very useful. However, when I suggested this for inclusion in RFC 190 I got a lot of pushback and didn't have a concrete convincing use case for either part of this proposal. Here's the best idea I've come up with: a "router" where the outputs are configured via factory configurations but the inputs are determined by clients connecting. Each connection request would include the "name" of the desired output. The connection listener would use this output name to look up the ComponentFactory corresponding to that output and use the newInstance method with properties derived from the connection request to create a DS instance whose properties merge the output configuration and the input configuration. Does this seem convincing? Does anyone have a better or more convincing use case? One reason this is important to try to get into the spec is that there's a problem with DTOs and factory components. The currently proposed DTOs work great for normal components where there are only 2 levels of configuration, the xml descriptor and (possibly) a bunch of configurations. The ComponentDescriptionDTO corresponds to the xml and the ComponentConfigurationDTO corresponds to the (merged) configurations. However this doesn't fit factory components, where you have: a. xml descriptor (clearly should be represented by the ComponentDescriptionDTO) b. ComponentFactory service configured by xml + bunch of configurations (although this configuration is not visible in the service properties) c. instances created by newInstance (could be well represented by ComponentConfigurationDTO) I think the configuration of the middle item, the CompomentFactory, is important and needs to be visible in the DTO structure. For instance if configuration is required but missing, you won't get a ComponentFactory registered and this fact should be visible in the DTOs. ComponentConfigurationDTO could sort of represent them but ComponentFactory instances don't actually bind any references, so the BoundReferenceDTO doesn't seem to apply too well. Furthermore if we follow my proposal and let factory configurations work with factory components, then the a to b relationship is 1..n as well as the b to c relationship being 1..n My best idea (which I'm not 1005 satisfied with) so far is: - ServiceComponentRuntime.getComponentConfigurationDTOs should return an empty collection if the description is for a factory component - add a new ComponentFactoryConfigurationDTO to represent (b). This would be similar to the CCDTO but maybe without any reference information - add methods to ServiceComponentRuntime: Collection<ComponentFactoryConfigurationDTO> getComponentFactoryConfigurationDTOs(ComponentDescriptionDTO) (returns empty collection for non-factory descriptions) Collection<ComponentConfigurationDTO> getComponentConfigurationDTOs(ComponentFactoryConfigurationDTO) Without my proposal to allow factory configurations with factory components, the first of these new methods would return a single ComponentFactoryConfigurationDTO (or null). So I'd like to get the combination proposal into the spec so the return cardinality of this hypothetical method doesn't constrain future extensions. Comments? thanks david jencks
