Hi BJ, great, thanks!
Did you enter it into bugzilla somewhere where I might find it by any chance? Thanks, Fredrik. On Thu, Dec 4, 2008 at 02:51, Alin Dreghiciu <[EMAIL PROTECTED]> wrote: > +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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
