[
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:
{code}
@AdapterService(adapteeService = AdapteeService.class, propagate=false)
class MyAdapter implements AdaptedService {
volatile AdapteeService adaptee;
@Start
Map<String, Object> start() {
// return a map with whatever service properties you want for the
adapted service.
}
{code}
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:
{code}
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() method:
Hashtable props = new Hashtable();
props.put(..,..);
component.setServiceProperties(props);
}
{code}
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
{code}
class MyActivator extends DependencyActivatorBase {
public void init(BundleContext context, DependencyManager m) throws Exception
{
m.add(createAdapterService(new AdapterParams()
.adaptee(Adaptee.class).filter("(foo=bar)").autoconfig("myfield").propagate(false));
m.add(createAspectService(new AspectParams()
.interface(OriginalService.class).filter("(foo=bar)").ranking(10).propagate(false));
}
{code}
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 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)
