+1. Please do so BJ. On Wed, Dec 3, 2008 at 10:11 PM, BJ Hargrave <[EMAIL PROTECTED]> wrote: > Excellent point. So the desired behavior is that DS can call any method the > declared implementation class could call itself. > > So then, DS can call activate/deactivate/bind/unbind methods of any > visibility (private, default, protected, public) if the method is defined by > the implementation class declared in the component description. But, if the > method is defined by a super class of the declared implementation class, DS > will only call it if the method has public or protected visibility or if it > has default visibility and the super class is in the same package as the > declared implementation class and loaded by the same class loader as the > declared implementation class. > > I will propose this change to the DS spec. > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [EMAIL PROTECTED] > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > From: > "Fredrik Alströmer" <[EMAIL PROTECTED]> > To: > "OSGi Developer Mail List" <[email protected]> > Date: 2008/12/03 10:35 > Subject: Re: [osgi-dev] DS / method visibility...? > Sent by: [EMAIL PROTECTED] > ________________________________ > > > Hi BJ, > > thanks for you're answer, although default-visibility methods are not > private, they're still not callable from the class hierarchy if the > class is not in the same package. However, the activate/bind methods > are perfect candidates to be used by unit-tests, and these are often > depending on the package-protected visibility. Wouldn't be easier in > that case to define it as 'whatever the implementation class would be > able to call', i.e. in the class itself, even private methods may be > called, in parent classes protected and public are always callable and > default is callable if it's the same package as the implementation > class? > > I assume since SCR is using reflection and traversing the hierarchy > anyway, such a check should be fairly cheap. It's also making the spec > more consistent with the Java environment, as you're suggesting is the > (quite reasonable i might add) rationale behind it, without adding > complexity. > > Greetings, > Fredrik. > > On Wed, Dec 3, 2008 at 15:50, BJ Hargrave <[EMAIL PROTECTED]> wrote: >> The reasoning is inheritance. Since a component implementation class can >> extend some other class, we wanted DS to only call methods which would be >> callable by the implementation class declared in the component >> description. >> If we allowed DS to call private methods, then this breaks the visibility >> of >> the class hierarchy. It would allow someone to extend some class and have >> DS >> call its private methods. >> -- >> >> BJ Hargrave >> Senior Technical Staff Member, IBM >> OSGi Fellow and CTO of the OSGi Alliance >> [EMAIL PROTECTED] >> office: +1 386 848 1781 >> mobile: +1 386 848 3788 >> >> >> From: "Fredrik Alströmer" <[EMAIL PROTECTED]> >> To: "OSGi Developer Mail List" <[email protected]> >> Date: 2008/12/03 04:33 >> Subject: [osgi-dev] DS / method visibility...? >> Sent by: [EMAIL PROTECTED] >> ________________________________ >> >> >> Hi, >> >> perhaps this question has been asked many times before, but here goes >> anyway: >> >> What's the rationale behind the fact that all methods that should be >> called by DS should be public or protected? Why is it not 'not >> private' (i.e. including default)? >> >> Thanks, >> Fredrik. >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
-- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
