[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Cannot bind services to multiply DS factory components

> Hello.
> 
> I have such component descriptions:
> 
> <component name="TestService" factory="TestServiceFactory">
>   <implementation class="testservice.TestServiceImpl"/>
>   <service>
>     <provide interface="testservice.TestService"/>
>   </service>
> </component>
> 
> <component name="TestServiceNew" factory="TestServiceNewFactory">
>   <implementation class="testservicenew.TestServiceNewImpl"/>
>   <service>
>     <provide interface="testservicenew.TestServiceNew"/>
>   </service>
>   <reference name="TESTSERVICE"
>     interface="testservice.TestService"
>     cardinality="0..n"
>     policy="dynamic"
>     bind="addTestService"
>     unbind="removeTestService"/>
> </component>
> 
> At first I instantiate let's say five TestService components with 
> it's factory. 

So at this point there should be 5 TestService services registered with 
the framework.

> Then I try to instantiate two TestServiceNew 
> components with it's factory. Everything seems OK except of one 
> thing: all five TestService are bound to first TestServiceNew, but 
> none of them is bound to second TestServiceNew! In log I have this 
warning:
> 

Yes this seems wrong. Each TestServiceNew component instance should have 
all five TestServices bound to it.

> WARNING 21 ComponentReference.bind(): service reference already 
> bound: {testservicenew.TestServiceNew}=
> {component.name=TestServiceNew, component.id=10, id=0, service.id=37}
> 
> I thinks this is happens because of DS thinks that all factory 
> components share same reference pool or something, so there is no 
> need to bind TestService to second instance of TestServiceNew, 
> because they are already bound to first instance. Is this true? If 
> it is, is there a way to override this behaviour or someway to 
> implement such behaviour that I need?

I think this is a bug in the DS impl. Please open a bug against 
Equinox->Bundles with this information and a test case to help reproduce 
the problem.

Thanks,

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx

office: +1 386 848 1781
mobile: +1 386 848 3788