Hi, Tom and BJ I got it. Thank you for the teaching.
Best Regards, ======= Ikuo YAMASAKI On Fri, 5 Jun 2009 09:38:17 -0600 BJ Hargrave <[email protected]> wrote: BJ> Yes. It means it is legal for a framework impl to return multiple distinct ServiceReference objects for a given service. So a bundle must not rely on == and must instead use equals() when trying to determine if 2 ServiceReferences refer to the same service. This is standard behavior for Maps. BJ> BJ> BTW The thunking layer of the framework 2.0 prototype Peter and I presented at JavaOne relies on this. BJ> BJ> BJ Hargrave BJ> Senior Technical Staff Member, IBM BJ> OSGi Fellow and CTO of the OSGi Alliance BJ> [email protected] BJ> Office: +1 386 848 1781 Mobile: +1 386 848 3788 BJ> BJ> BJ> ----- Original Message ----- BJ> From: Ikuo Yamasaki [[email protected]] BJ> Sent: 06/05/2009 08:08 PM ZE9 BJ> To: [email protected] BJ> Subject: [osgi-dev] Multiple ServiceReference for one ServiceRegistration ? BJ> BJ> BJ> BJ> Hi OSGi Experts, BJ> BJ> I have a question in the core spec. BJ> BJ> ------------------ BJ> 6.1.23 public interface ServiceReference extends Comparable BJ> BJ> page 186 in R4.1 Core Spec BJ> BJ> Every service registered in the Framework has a unique ServiceRegistration BJ> object and may have multiple, distinct ServiceReference objects referring to BJ> it. BJ> ------------------ BJ> BJ> What kind of cases are multiple ServiceReference objects are needed for BJ> a unique ServiceRegistration? (only one object is needed, IMO). BJ> BJ> # Does it mean "there might be a framework impl, which returns distinct BJ> # ServiceReference objects for every time when BJ> # BundleContext#getServiceReference(s) is called, BJ> # although it is not required in theory" ? BJ> BJ> Best regards, BJ> BJ> BJ> --------------------- BJ> NTT Cyber Solutions Laboratories BJ> BJ> Ikuo YAMASAKI BJ> E-mail: [email protected] BJ> TEL +81-46-859-8537 FAX +81-46-855-1282 BJ> BJ> BJ> _______________________________________________ BJ> OSGi Developer Mail List BJ> [email protected] BJ> https://mail.osgi.org/mailman/listinfo/osgi-dev BJ> BJ> _______________________________________________ BJ> OSGi Developer Mail List BJ> [email protected] BJ> https://mail.osgi.org/mailman/listinfo/osgi-dev BJ> _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
