[jira] [Updated] (FELIX-4600) Cherrypicking of propagated properties

["Tuomas Kiviaho (JIRA)" <ji...@apache.org>]

     [ 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 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.-

  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.

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 boundady 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 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.-



--
This message was sent by Atlassian JIRA
(v6.2#6252)