felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Pozolotin <andrei.pozolo...@gmail.com>
Subject Re: [DS] A new style of factory components
Date Wed, 30 Oct 2013 19:32:04 GMT
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
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message