Hi PIerre, comments inline
On Oct 30, 2013, at 2:13 PM, Pierre De Rop <[email protected]> wrote:
> Hi David,
>
> Interesting post.
>
> Whilst the workarounds mentioned by Andrei are powerful (very nice
> articles, Andrei !), I tend to think that the improvements you are
> suggesting would certainly considerably ease the usage of Declarative
> Service factory components.
>
> Some comments:
>
> 1. Why not returning ExtComponentInstance from ComponentFactory.newInstance
> (instead of FactoryInstance) ? There is currently an extension in the Felix
> scr implementation:
>
> ./src/main/java/org/apache/felix/scr/component/ExtComponentContext.java
>
> So, we could just add
>
> ./src/main/java/org/apache/felix/scr/component/ExtComponentInstance.java
>
> and in that method, we could then add the new "modify" method.
I'm hoping to get this in the next spec (RFC 190, R6). If I can't or if I
start implementing before the spec discussion gets very far that's what I'll do.
>
> 2. Isn't it preferable to activate the new behavior in a property, instead
> of adding some new attributes in the xml and annotations ?
If it gets in the spec, we'd need xml + annotations. An SCR property would
certainly work, but break the current style of component factories.
>
> 3. Now, there is another point: currently, the spec says that factory
> components must not be registered with service properties. I'm wondering
> why there is such restriction. I have use cases where I need to depend on
> ComponentFactories with some specific service properties. Currently, this
> is not possible, and the only workaround is to prefix all factory component
> names, and then choose the CF with names starting with the prefix I'm
> interested in.
>
> So, would it make sense to also allow to register CF with some service
> properties:
>
> @Component(factory="factoryname", property={..})
I think the existing property and properties annotations are needed as the
default configuration of the components you create with newInstance. I agree
it would be good to allow specifying additional properties on the
ComponentFactory service. Maybe an additional xml element/ "factoryProperty"
annotation field?
>
> - If a ComponentFactory is registered even when References are unsatisfied,
> then what will return the getInstance() method of the ComponentInstance
> returned by the CF.newInstance() ? So, what I mean is that the new behavior
> seems to break the usage of getInstance() method. What do you think ?
I assumed getInstance() could return null for these new style component
factories when there wasn't actually an instance created. If you also specify
service-factory, I'm not quite sure what should be returned.
Thanks!
david jencks
>
> best regards;
> /Pierre
>
>
>
>
> On Wed, Oct 30, 2013 at 8: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
>>>
>>>
>>
>>
