felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre De Rop <pierre.de...@gmail.com>
Subject Re: [DS] A new style of factory components
Date Wed, 30 Oct 2013 21:13:30 GMT
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.

2. Isn't it preferable to activate the new behavior in a property, instead
of adding some new attributes in the xml and annotations ?

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={..})

- 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 ?

best regards;
/Pierre




On Wed, Oct 30, 2013 at 8:32 PM, Andrei Pozolotin <
andrei.pozolotin@gmail.com> 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 <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