[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] DS optional cardinality question

Yes, but then you will still need to use the locateService method to 
obtain the actual service object.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



"Richard S. Hall" <heavy@xxxxxxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
2006-03-02 10:37 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

Subject
Re: [equinox-dev] DS optional cardinality question






I think it is also possible to have your bind methods take a 
ServiceReference, which would not require that the listener components 
are activated until the service object is retrieved, no?

-> richard

BJ Hargrave wrote:
> Yes. If you want to delay activating the listener component until they 
are 
> actually needed, then you need to use the lookup strategy. 
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@xxxxxxxxxx
> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>
>
>
> Roy Paterson/Austin/IBM@IBMUS 
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 2006-03-02 09:49 AM
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
> To
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [equinox-dev] DS optional cardinality question
>
>
>
>
>
>
>
> I think this is working as designed.  Declarative Services will call the 

> bind method on Manager before it calls Manager's activate Method.  It 
does 
> not matter that the reference is optional.  The "optional" setting only 
> controls whether the Manager will be activated or not - it has no 
bearing 
> on the lifecycle of Listener1 or Listener2. 
>
> Regards, 
> Roy
>
> -----------------------------------------
> Roy Paterson
> IBM Pervasive Computing
> Austin, TX
> Phone: (512) 838-8898
>
>
>
> Subbarao Meduri/Durham/IBM@IBMUS 
> Sent by: equinox-dev-bounces@xxxxxxxxxxx 
> 03/01/2006 10:02 PM 
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
> To
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 
> cc
>
> Subject
> [equinox-dev] DS optional cardinality question
>
>
>
>
>
>
>
>
> I have a simple collaborator pattern where a Manager component has a 
> optional multiple reference to several Listener services as shown below:
>
> <component 
> name="Manager" immediate="true">
> <implementation class="com.ibm.listener.Manager"/>
> <reference
> name="Listener"
> interface="com.ibm.listener.Listener"
> cardinality="0..n"
> policy="dynamic"
> bind="addListener"
> unbind="removeListener"
> />
> </component>
>
> <component 
> name="Listener1">
> <implementation class="com.ibm.listener.Listener1"/>
> <service>
> <provide interface="com.ibm.listener.Listener"/>
> </service>
> </component>
>
> <component 
> name="Listener2">
> <implementation class="com.ibm.listener.Listener2"/>
> <service>
> <provide interface="com.ibm.listener.Listener"/>
> </service>
> </component>
>
> Components Listener1 and Listener2 are not immediate components, where 
as 
> the Manager component is. I would think that DS will activate Manager 
> component without having to activate Listener1 or Listener 2 as they are 

> not immediate components, and they are not mandatory for Manager (0..n 
> cardinality). However, when I ran this example (with M5 bundles), both 
> Listener 1 and Listener 2 were activated and injected into Manager 
> component. Could this be a bug ?
>
> Regards,
> Subbarao_______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> 
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev