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] [Commented] (FELIX-4600) Cherrypicking of propagated properties
Date Mon, 27 Oct 2014 21:32:35 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185858#comment-14185858

Pierre De Rop commented on FELIX-4600:

(Sorry Tuomas for the delay)

So, indeed, the following improvements could be done:

1) As you suggested, in the API, when creating adapters or aspects,  we could add a "propagate"
flag in order to turn off automatic adaptee or aspect service properties propagation.

2) This also means that the propagate flag has to also be added in the corresponding @Adapter
and @Aspect.

And from the start method annotated with @Start, you could then cherrypick the service properties
and put them in the map returned by the @Start method.

But currently, only the DM Runtime allows you to return a Map<String, Object> from the
@Start method:

@AdapterService(adapteeService = AdapteeService.class, propagate=false)
class MyAdapter implements AdaptedService {
   volatile AdapteeService adaptee;

   Map<String, Object> start() {
       // return a map with whatever service properties you want for the adapted service.

and if you are only using the DM API (not the annotations), then you will have to get injected
with the Component object from the API and use the Component.setServiceProperties() method
in order to provide the service properties from your start method:

class MyAdapter implements AdaptedService {
   volatile AdapteeService adaptee;
   volatile Component component;

  void start() {
       // Set whatever service properties you want for the adapted service, using component.setServiceProperties()

       Hashtable props = new Hashtable();

So, I am now tempted to do a two other improvement (3, and 4):

3) When using the API, allow to return the properties map from the start() method, like it
is currently the case for Annotations.

4) Since we would now have many signatures for aspect and adapters, then maybe we could use
a "builder" parameter pattern for aspect and adapters. Something like

class MyActivator extends DependencyActivatorBase {
  public void init(BundleContext context, DependencyManager m) throws Exception { 
    m.add(createAdapterService(new AdapterParams()

     m.add(createAspectService(new AspectParams()

This would allow to only have two signatures: one for adapters, and one for aspects, and all
possible parameters could then be stored in the AdapterParams and AspectParams.

Marcel, what do you think ? Is it fine for you if we go for the four improvements ? or only
for the first two (1, 2) or (1,2,3) ?

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