Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] ProSyst Declarative Services: Multiple calls to activate() for single service instance

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



Back to the top