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 <kemu...@gmail.com> wrote: > > On Sun, May 22, 2016 at 4:24 PM, David Jencks > <david_jen...@yahoo.com.invalid <mailto:david_jen...@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 <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 >> <mailto:users-unsubscr...@felix.apache.org> >> For additional commands, e-mail: users-h...@felix.apache.org >> <mailto:users-h...@felix.apache.org> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > <mailto:users-unsubscr...@felix.apache.org> > For additional commands, e-mail: users-h...@felix.apache.org > <mailto:users-h...@felix.apache.org>
