That bug talks about a deadlock, which isn't what we're seeing in this case. In this scenario, the service lookup completes fine, it's just that activate() gets called for a second time on the instance as part of locating the service. (Even if part of the patch for the bug you're referring touches the code right after the bit I quoted above...)
I'll have a look through the other bug reports and recent patches though, to see if any match our problem. Thanks, Jan On 07/08/07, Jeremy Volkman < [EMAIL PROTECTED]> wrote: > > Jan, > > Sounds like you might be running into > https://bugs.eclipse.org/bugs/show_bug.cgi?id=186280 > > -Jeremy > > On 8/7/07, Jan Stette < [EMAIL PROTECTED] > wrote: > > (Changing threads as I've gone slightly off-topic now) > > > > As a concrete example of a problem we're seeing is that we have a > service on > > which activate() is called twice on the same service instance, i.e. the > same > > object, without any intermediate calls to deactivate(). Is that > something > > that can legally occur in any circumstance? > > This service has only static references, and references to it are all > static > > too. Felix, could you elaborate on how you think thes e policies could > be > > affecting the issue? > > > > Also, none of these services are registered as service factories in > > themselves (though I guess DS registers a service factory on their > behalf as > > discussed below?) > > > > Anyway, what we're seeing is basically this sequence of events: > > - A service (X) is "immediate" so is registered on startup. > > - Some time (much) later, a service (Y) declared in another bundle tries > to > > locate service X. > > - This service is looked up OK so the right instance is found, but > activate > > is called on the method again. > > > > Stepping through the code of the Declarative Services bundle we're using > > > (The ProSyst supplied equinox one), 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) above should have been > called > > inside the 'if' statement, i.e. only when creating a new instance? > > > > Apologies if discussing details of an implementation if out of scope on > this > > list, but your comments on what is correct behaviour from the DS > framework > > in this case would be highly appreciated. > > > > Regards, > > Jan > > > > > > On 07/08/07, Alexander Horn < [EMAIL PROTECTED]> wrote: > > > > I can't see any circumstance where a valid DS implementation should > > register > > > > a component with a single name several times, though I guess it's > > possible > > > > we are doing something wrong somewhere to trigger this condition. > > > > > > Of course, I don't know your situation in great detail but maybe what > > > your experiencing is due to the binding policy of your references. > > > > > > ... > > > <reference policy="static" /> vs. <reference policy="dynamic" /> > > > > > > On 8/7/07, BJ Hargrave < [EMAIL PROTECTED]> wrote: > > > > If the pid is a factory configuration, then the component will be > > > > activated once for each configuration of the factory. > > > > -- > > > > > > > > BJ Hargrave > > > > Senior Technical Staff Member, IBM > > > > OSGi Fellow and CTO of the OSGi Alliance > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > http://www2.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
