Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of andrei.pozolotin@gmail.com
 designates 209.85.214.172 as permitted sender)
Message-ID: <52715EB4.1000608@gmail.com>
Date: Wed, 30 Oct 2013 14:32:04 -0500
From: Andrei Pozolotin <andrei.pozolotin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: [DS] A new style of factory components
References: <054BAFAB-EE5C-416B-A661-449978A11E27@yahoo.com>
In-Reply-To: <054BAFAB-EE5C-416B-A661-449978A11E27@yahoo.com>
Content-Type: multipart/alternative;
 boundary="------------080502060608090703070000"

--------------080502060608090703070000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <david_jencks@yahoo.com>
To: dev@felix.apache.org <dev@felix.apache.org>
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
>
>


--------------080502060608090703070000--