Agreed... in fact this behaviour is mentioned in the spec: OSGi Core Specification, section 5.9.1.
Regards Neil On Fri, Jun 7, 2013 at 12:11 AM, Felix Meschberger <[email protected]>wrote: > Hi > > Am 06.06.2013 um 15:31 schrieb Agemo Cui: > > > On 6/6/13 11:09 AM, Carsten Ziegeler wrote: > >> 2013/6/6 Agemo Cui <[email protected]> > >> > >>> > >>> On 6/6/13 5:21 AM, Chetan Mehrotra wrote: > >>> > >>>> I have at times also struggled with DS when I moved from Blueprint. > Within > >>>> a Bundle if there are some internal services which are used by > various DS > >>>> Components *within* that bundle then is it fine to > >>>> > >>>> 1. Register these internal services as DS components but with classes > >>>> which > >>>> are not part of Export-Package list i.e. private classes > >>>> > >>> Yes (at least) for Apache SCR. > >>> > >> Do you mean, this doesn't or might not work with other DS > implementations? > > > > Yes. Because Im not sure if this is mentioned in the spec. > > However, it works in my case using felix scr. > > Why should that not work ? A service registered with a service > interface/class name and the service registry does not care whether this is > actually exported or not. What the service registry does is make sure that > the consumer can use the service, thus knows the service interface/class > (unless the getAllServiceReferences method is used). > > Regards > Felix > > > > >> > >>> But other bundles are not really prevented from using this service by > this > >>> method. > >>> The service still can be fetched, and be used through reflection. > >>> > >>> I don't think this is a problem - you can do all kinds of tricks using > >> reflection etc. > >> However, I'm not sure if you're really able to get the service as > >> ServiceReference.isAssignableTo is called and if I understand this > >> correctly, this will fail as the client bundle does not see the private > >> class under which the service is registered. > > Sorry, it's not a problem > > > > > >> > >> Carsten > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
