Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
On Mon, May 23, 2016 at 12:18 PM, David Jenckswrote: > Looking into this more, the reason I didn’t support List 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 >> 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 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-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
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
Looking into this more, the reason I didn’t support List 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> 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 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 wrote: >> >> On Sun, May 22, 2016 at 4:24 PM, David Jencks >> > >> 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 >> 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 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 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 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
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
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 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 Walterswrote: > > On Sun, May 22, 2016 at 4:24 PM, David Jencks > > > 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 > 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 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 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 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
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
On Sun, May 22, 2016 at 4:24 PM, David Jenckswrote: > 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 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 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 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 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
Re: OSGi R6/DS 1.3 + Felix + Bnd: Interfaces in Component Lifecycle methods
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 Mapto 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 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 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=markup#l296 > [1] - > http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/inject/ActivateMethod.java?revision=1744740=markup#l246 > > - > To unsubscribe, e-mail: