I originally posted this issue to the osgi-dev list as I wasn't sure if the
seen behavior was allowed by the spec or not. The comments there suggest
that this looks like a bug, so I'm posting this here. This problem is seen
using the ProSyst declarative services implementation as originally
contributed to Eclipse.
What we're seeing is basically this sequence of events:
- A service (X) is "immediate" so is registered on startup, and activated.
- Some time (much) later, a service (Y) declared in another bundle tries to
locate service X through the ComponentContext.locateService() method.
- This service is looked up OK so the right instance is found, but
activate() is called on the service instance again.
Stepping through the Declarative Services code it seems to indeed find the
existing service within the corresponding ServiceFactory as registered by
the DS bundle ( i.e. the "proxy" service). However, after finding the
existing service, it still calls activate() on it. The specific code
fragment looks like:
<...look up the component instance, in this case finding it... so the if()
statement below tests as false. >
if (componentInstance == null) {
componentInstance = new ComponentInstanceImpl(instance, this);
componentInstance.setComponentContext(new ComponentContextImpl(
this, usingBundle, componentInstance, mgr));
}
bind(componentInstance);
activate(usingBundle, componentInstance);
<return the component instance>
To me, it seems like activate() (and maybe bind) should have been called
inside the 'if' statement, i.e. only when creating a new instance? That's
just a guess based on my first look at the code though!
Note that we only see this issue when the service is accessed the second
time from outside its own bundle. From looking at the framework code, I
suspect this is because service objects are cached for each bundle? In any
case, this is something to bear in mind if trying to reproduce this.
Regards,
Jan
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
