[ https://issues.apache.org/jira/browse/FELIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tuomas Kiviaho updated FELIX-4600: ---------------------------------- Description: Currently osgi.command.scope and osgi.command.function flood down from my {{@AdapterService}} because there is no propagation prevention mechanism as per {{@BundleAdapterService}} (also mentioned at FELIX-4594). This also applies {{@AspectService}} annotation. Still with these options the propagation from adapters/aspects is currently uncontrollable compared to dependencies where - albeit cumbersome - you still can write your own logic. My use case is with propagated adapter/aspect identity properties (such as service.pid, jmx.objectname, osgi.command.scope, osgi.command.function) that I'd rather not see automatically propagated. There is already a {{setPropagate(Object, String)}} method in {{ServiceDependency}}. I think this mechanism could also be available for annotations alongside the {{propagate}} boolean property. (Perhaps a {{String propagated() default ""}}) -I suggest that internal m_serviceProperties would be changed as map (since @Start annotation allows this already) and keys with null values would be considered non-propagable. Internal map would be converted to Dictionary each time in passes API/Impl boundary and at this point keys with null values would be dropped.- was: Currently osgi.command.scope and osgi.command.function flood down from my {{@AdapterService}} because there is no propagation prevention mechanism as per {{@BundleAdapterService}} (also mentioned at FELIX-4594). This also applies {{@AspectService}} annotation. Still with these options the propagation from adapters/aspects is currently uncontrollable compared to dependencies where - albeit cumbersome - you still can write your own logic. My use case is with propagated adapter/aspect identity properties (such as service.pid, jmx.objectname, osgi.command.scope, osgi.command.function) that I'd rather not see automatically propagated. There is already a {{setPropagate(Object, String)}} method in {{ServiceDependency}}. I think this mechanism could also be available for annotations either alongside the {{propagate}} property or if backward compatibility is not an issue then current property could take in either Boolean or String values of which the latter would be interpreted as method name. -I suggest that internal m_serviceProperties would be changed as map (since @Start annotation allows this already) and keys with null values would be considered non-propagable. Internal map would be converted to Dictionary each time in passes API/Impl boundary and at this point keys with null values would be dropped.- > Cherrypicking of propagated properties > -------------------------------------- > > Key: FELIX-4600 > URL: https://issues.apache.org/jira/browse/FELIX-4600 > Project: Felix > Issue Type: Wish > Components: Dependency Manager > Affects Versions: dependencymanager.annotations-3.2.0, > dependencymanager.runtime-3.2.0 > Reporter: Tuomas Kiviaho > > Currently osgi.command.scope and osgi.command.function flood down from my > {{@AdapterService}} because there is no propagation prevention mechanism as > per {{@BundleAdapterService}} (also mentioned at FELIX-4594). This also > applies {{@AspectService}} annotation. > Still with these options the propagation from adapters/aspects is currently > uncontrollable compared to dependencies where - albeit cumbersome - you still > can write your own logic. > My use case is with propagated adapter/aspect identity properties (such as > service.pid, jmx.objectname, osgi.command.scope, osgi.command.function) that > I'd rather not see automatically propagated. > There is already a {{setPropagate(Object, String)}} method in > {{ServiceDependency}}. I think this mechanism could also be available for > annotations alongside the {{propagate}} boolean property. (Perhaps a > {{String propagated() default ""}}) > -I suggest that internal m_serviceProperties would be changed as map (since > @Start annotation allows this already) and keys with null values would be > considered non-propagable. Internal map would be converted to Dictionary each > time in passes API/Impl boundary and at this point keys with null values > would be dropped.- -- This message was sent by Atlassian JIRA (v6.2#6252)