You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Steven Walters <ke...@gmail.com> on 2016/05/22 04:51:15 UTC
OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
Posted by Steven Walters <ke...@gmail.com>.
On Mon, May 23, 2016 at 12:18 PM, David Jencks
<da...@yahoo.com.invalid> wrote:
> Looking into this more, the reason I didn’t support List<Foo> etc originally is that its much more complicated to deal with figuring out the type information than with an array.
>
> I’m not going to add this support directly, but will look into starting to use the object converter service when it seems more or less ready. I have to investigate whether the nested object key encoding scheme implemented in DS can be added to a spec converter using an adapter.
>
> Meanwhile, can you use an array?
Yes I can, I was just simply trying to experiment with the use of
interfaces and something that would warrant the use of an interface (a
non primitive type that can't be used on an annotation),
I had an array originally in the annotation, so I simply switched to a
List to force the usage of an interface.
Collections and similar generic types would be likely more complicated
to handle with the type erasure aspect that is associated with their
use.
I'll probably just stick with using annotations going forward though,
using implementation specific enhancements can cause some significant
headache later
(especially since I don't know how other OSGi R6/DS 1.3
implementations may or may not support the same extended
functionality).
This has been a good learning experience though as this is my first
time in using the DS 1.3 annotations, as a migration from previously
using the Felix SCR annotations, so I do very much appreciate your
effort and feedback.
Thanks,
Steven
>
> thanks
> david jencks
>
>> On May 22, 2016, at 9:59 AM, David Jencks <da...@yahoo.com.INVALID> wrote:
>>
>> This extension has been used, I think, mostly by me, so the limitations are the things I’ve not happened to run up against. At the moment the only kinds of interfaces that DS supports are ones that look like annotations except for inheritance. So you can only have primitive, String, Class, interface, and arrays of the previous as return types. We’re treating the List<Long> return type as an interface valued return type rather than something like long[] as you expect. DS doesn’t have access to the metatype information.
>>
>> I’ll see if I can find time to support List, Set, Collection return types for 2.0.4. I need to consult the draft object conversion spec to see what might be reasonable.
>>
>> thanks
>> david jencks
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
Posted by David Jencks <da...@yahoo.com.INVALID>.
Looking into this more, the reason I didn’t support List<Foo> etc originally is that its much more complicated to deal with figuring out the type information than with an array.
I’m not going to add this support directly, but will look into starting to use the object converter service when it seems more or less ready. I have to investigate whether the nested object key encoding scheme implemented in DS can be added to a spec converter using an adapter.
Meanwhile, can you use an array?
thanks
david jencks
> On May 22, 2016, at 9:59 AM, David Jencks <da...@yahoo.com.INVALID> wrote:
>
> This extension has been used, I think, mostly by me, so the limitations are the things I’ve not happened to run up against. At the moment the only kinds of interfaces that DS supports are ones that look like annotations except for inheritance. So you can only have primitive, String, Class, interface, and arrays of the previous as return types. We’re treating the List<Long> return type as an interface valued return type rather than something like long[] as you expect. DS doesn’t have access to the metatype information.
>
> I’ll see if I can find time to support List, Set, Collection return types for 2.0.4. I need to consult the draft object conversion spec to see what might be reasonable.
>
> thanks
> david jencks
>
>> On May 22, 2016, at 4:54 AM, Steven Walters <ke...@gmail.com> wrote:
>>
>> On Sun, May 22, 2016 at 4:24 PM, David Jencks
>> <david_jencks@yahoo.com.invalid <ma...@yahoo.com.invalid>> wrote:
>>> 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
>>
>> So I got the XML generation to work successfully when using
>> maven-bundle-plugin from current source, apparently 3.0.1 uses a
>> version of bnd that doesn't recognize/handle the 'mapping' attribute
>> correct, so the generated XML was incorrect when using 3.0.1
>>
>> However, after this, on attempt of calling one of the LC methods
>> utilizing the interface, an NPE gets thrown with the SCR 2.0.2's
>> handling of the configured properties.
>> My interface I'm attempting to utilize in the @Activate method has a
>> List<Long> return type.
>> This seems to eventually dive into the
>> org.apache.felix.scr.impl.helper.Annotations (trunk seems to have
>> moved this to org.apache.felix.scr.impl.inject.Annotations) where the
>> use of extractSubMaps ignores the existing Vector<Long> that is
>> defined for the attribute in the property map (it is a Vector due to
>> the negative cardinality that is generated due to the use of a
>> Collection on the type).
>> the functionality instead appears to use some pattern matching scheme
>> that assumes that the values of the attribute are independent numbered
>> attributes with the prefix of the attribute name, causing the
>> resulting returned map be empty.
>>
>> In the end, the functionality currently causes the proplist at
>> List<Map<String, Object>> proplist = nested.get(entry.getKey());
>> be null and throw an NPE on later attempted use.
>>
>> The currently functionality as written seems to be only geared towards
>> nested object handling, and not collections, so thus the unexpected
>> null error condition.
>>
>> All in all, this is turning into a big mess of continual issues, so
>> obviously indicating that this is a path not meant to be traveled for
>> now, and really do just stick with the use of annotations and
>> therefore also the restriction to primitive types.
>>
>> Thanks for the help/clarity,
>> Steven.
>>
>>>
>>> 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 <ke...@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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
Posted by David Jencks <da...@yahoo.com.INVALID>.
This extension has been used, I think, mostly by me, so the limitations are the things I’ve not happened to run up against. At the moment the only kinds of interfaces that DS supports are ones that look like annotations except for inheritance. So you can only have primitive, String, Class, interface, and arrays of the previous as return types. We’re treating the List<Long> return type as an interface valued return type rather than something like long[] as you expect. DS doesn’t have access to the metatype information.
I’ll see if I can find time to support List, Set, Collection return types for 2.0.4. I need to consult the draft object conversion spec to see what might be reasonable.
thanks
david jencks
> On May 22, 2016, at 4:54 AM, Steven Walters <ke...@gmail.com> wrote:
>
> On Sun, May 22, 2016 at 4:24 PM, David Jencks
> <david_jencks@yahoo.com.invalid <ma...@yahoo.com.invalid>> wrote:
>> 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
>
> So I got the XML generation to work successfully when using
> maven-bundle-plugin from current source, apparently 3.0.1 uses a
> version of bnd that doesn't recognize/handle the 'mapping' attribute
> correct, so the generated XML was incorrect when using 3.0.1
>
> However, after this, on attempt of calling one of the LC methods
> utilizing the interface, an NPE gets thrown with the SCR 2.0.2's
> handling of the configured properties.
> My interface I'm attempting to utilize in the @Activate method has a
> List<Long> return type.
> This seems to eventually dive into the
> org.apache.felix.scr.impl.helper.Annotations (trunk seems to have
> moved this to org.apache.felix.scr.impl.inject.Annotations) where the
> use of extractSubMaps ignores the existing Vector<Long> that is
> defined for the attribute in the property map (it is a Vector due to
> the negative cardinality that is generated due to the use of a
> Collection on the type).
> the functionality instead appears to use some pattern matching scheme
> that assumes that the values of the attribute are independent numbered
> attributes with the prefix of the attribute name, causing the
> resulting returned map be empty.
>
> In the end, the functionality currently causes the proplist at
> List<Map<String, Object>> proplist = nested.get(entry.getKey());
> be null and throw an NPE on later attempted use.
>
> The currently functionality as written seems to be only geared towards
> nested object handling, and not collections, so thus the unexpected
> null error condition.
>
> All in all, this is turning into a big mess of continual issues, so
> obviously indicating that this is a path not meant to be traveled for
> now, and really do just stick with the use of annotations and
> therefore also the restriction to primitive types.
>
> Thanks for the help/clarity,
> Steven.
>
>>
>> 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 <ke...@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
Posted by Steven Walters <ke...@gmail.com>.
On Sun, May 22, 2016 at 4:24 PM, David Jencks
<da...@yahoo.com.invalid> wrote:
> 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
So I got the XML generation to work successfully when using
maven-bundle-plugin from current source, apparently 3.0.1 uses a
version of bnd that doesn't recognize/handle the 'mapping' attribute
correct, so the generated XML was incorrect when using 3.0.1
However, after this, on attempt of calling one of the LC methods
utilizing the interface, an NPE gets thrown with the SCR 2.0.2's
handling of the configured properties.
My interface I'm attempting to utilize in the @Activate method has a
List<Long> return type.
This seems to eventually dive into the
org.apache.felix.scr.impl.helper.Annotations (trunk seems to have
moved this to org.apache.felix.scr.impl.inject.Annotations) where the
use of extractSubMaps ignores the existing Vector<Long> that is
defined for the attribute in the property map (it is a Vector due to
the negative cardinality that is generated due to the use of a
Collection on the type).
the functionality instead appears to use some pattern matching scheme
that assumes that the values of the attribute are independent numbered
attributes with the prefix of the attribute name, causing the
resulting returned map be empty.
In the end, the functionality currently causes the proplist at
List<Map<String, Object>> proplist = nested.get(entry.getKey());
be null and throw an NPE on later attempted use.
The currently functionality as written seems to be only geared towards
nested object handling, and not collections, so thus the unexpected
null error condition.
All in all, this is turning into a big mess of continual issues, so
obviously indicating that this is a path not meant to be traveled for
now, and really do just stick with the use of annotations and
therefore also the restriction to primitive types.
Thanks for the help/clarity,
Steven.
>
> 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 <ke...@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <ke...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org