felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (FELIX-4600) Cherrypicking of propagated properties
Date Fri, 16 Jan 2015 23:19:34 GMT

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

Pierre De Rop resolved FELIX-4600.
    Resolution: Fixed

Hello Tuomas,

We would like to make a release soon, and since the support for a "propagate" flag in the
adapters has already been implemented, I'm setting this issue to resolved.  But If you really
need the support for a propagate flag also for aspects, then I propose to discuss about that
later, after the dm 4.0.0 will be released.

> 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
>            Assignee: Pierre De Rop
>             Fix For: dependencymanager-4.0.0, dependencymanager.annotations-4.0.0, dependencymanager.runtime-4.0.0
> 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
> -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

View raw message