It all does work, sorry I haven’t really documented it.  I only use bndlib from 
ant, but I use a slightly pre bnd 3.1 version so I’d guess it might all work 
with recent maven-bundle-plugin.

There are two things you can set:

-dsannotations-options in the bnd.bnd file or equivalent:

inherit has bnd analyze superclasses of your component looking for additional 
annotations.

felixExtensions allows lifecycle and event methods to return Map<String, 
Object> to set the service properties, and allows configuration with interfaces 
rather than annotations

extender sets the namespace version to 1.3 so you always get the require 
capability on the DS implementation.


Then you can use the DSExt annotations in the scr-ext-anno project (I think you 
have to build this yourself at the moment) to have bnd add stuff to the 
generated component xml descriptor

@DSExt.ConfigurableServiceProperties tells DS to allow the lifecycle and event 
methods to return a Map<String, Object> to set the service properties.

@DSExt.PersistentFactoryComponent alters the lifecycle of factory components 
(the components created from a ComponentFactory.newInstance(props) invocation) 
to be the same as a normal component instead of the somewhat useless lifecycle 
mandated by the spec.

@DSExt.DeleteCallsModify adjusts the behavior of pre-ds-1.3 component to match 
the 1.3 behavior for a component with a modified method when the configuration 
is deleted and the component is still satisfied (configuration optional or some 
other targeted pid available)

@DSExt.ObsoleteFactoryComponentFactory Dont even think about using this.  
Backwards compatibility only.

@DSExt.ConfigureWithInterfaces allows lifecycle methods to accept interfaces 
rather than annotations

@DSExt.DelayedKeepInstances when applied to a delayed component, once the 
component is created it isn’t automatically deactivated when all the uses of it 
are returned.

So, to configure with interfaces rather than annotations, you need to tell bnd 
by using the 

-dsannotations-options: felix-extensions

and tell felix DS by using the 
@DSExt.ConfigureWithInterfaces

The reason the spec says to use annotations rather than interfaces is so that 
the annotation defaults can be put into the property map as the 
no-configuration values.  Otherwise you’d need to either write them out by hand 
in the @Component annotation or use both metatype and config admin and specify 
then in the metatype defaultValue.

Hope this helps
david jencks

> On May 21, 2016, at 9:51 PM, Steven Walters <kemu...@gmail.com> wrote:
> 
> I've found that Felix appears to have an extension to the OSGi R6/DS
> 1.3 specification regarding configuration of components.
> 
> In that @Active, @Deactivate, and @Modified methods can by configured
> by an interface in addition to an annotation.
> per at least [0] & [1]
> 
> However, bnd itself does not seem to be rather happy with this, and
> when using maven-bundle-plugin 3.0.1, the build will fail due to this.
> Though using bnd directly seems to be treating this more as a warning,
> as it still writes the activate, deactivate, and modified attributes
> as normal.
> (That or the ability to still write the XML as expected may be an
> artifact of using a newer bnd that what the maven-bundle-plugin
> utilizes)
> 
> Also, The felix extension point indicator is in the component
> definition XML (which is normally generated by bnd when using the OSGi
> R6 annotations).
> Is there actually any expectation that bnd is able to support the
> felix specific extension point here?
> I'm currently seeing this as having to forego the annotations and
> write the XML manually for at least these particular "violating"
> components, which would be a decent cause for tedium and confusion
> later.
> 
> 
> This restriction to only allowing the use of annotation types in the
> component lifecycle methods seems a bit contrary.
> @ObjectClassDefinition explicitly states that it can specified on
> interfaces (and handling interface hierarchy), but if interfaces can
> not be used as part of the component lifecycle method signatures, then
> this feels like the use of metatyping interfaces is rather
> non-beneficial.
> 
> This currently seems like a lack of friendliness in the specification,
> which is why the Felix project created the enhancement point...
> But I'm not actually all that familiar with the specification to be
> confident in this viewpoint.
> 
> Any clarity/feedback that could be provided on the matter here would
> be greatly appreciated.
> 
> Thanks,
> Steven
> 
> [0] - 
> http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java?revision=1744737&view=markup#l296
> [1] - 
> http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/inject/ActivateMethod.java?revision=1744740&view=markup#l246
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to