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