[ 
https://issues.apache.org/jira/browse/FELIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre De Rop updated FELIX-4600:
---------------------------------
    Fix Version/s:     (was: dependencymanager.runtime-4.0.0)
                       (was: dependencymanager.annotations-4.0.0)
                       (was: dependencymanager-4.0.0)
                   org.apache.felix.dependencymanager-r1

> Cherrypicking of propagated properties
> --------------------------------------
>
>                 Key: FELIX-4600
>                 URL: https://issues.apache.org/jira/browse/FELIX-4600
>             Project: Felix
>          Issue Type: Wish
>          Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Runtime
>    Affects Versions: dependencymanager.annotations-3.2.0, 
> dependencymanager.runtime-3.2.0
>            Reporter: Tuomas Kiviaho
>            Assignee: Pierre De Rop
>             Fix For: org.apache.felix.dependencymanager-r1
>
>
> 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.3.4#6332)

Reply via email to