"Alan D. Cabrera" <[EMAIL PROTECTED]> wrote on 2005-08-26 03:26:52 PM:
> On 8/26/2005 11:01 AM, BJ Hargrave wrote: > > >Well it is not just for optimization. It is necessary for a Framework impl > >to customize the OSGi supplied AdminPermission and BundleSignerCondition > >classes. This is one of the reasons OSGi releases this code under an OSL. > >Because we know that framework impls MUST modify this code to hook into > >framework impl details. > > > > > For those of us who are not OSGi implementation gurus, could you explain > why these classes need to be customized? I did a *cursory* glance > through the spec and it's not clear to me. For example, BundleSignerCondition needs access to (1) filter implementation logic in the framework impl and (2) access to DN chain information for bundles to evaluate filter strings. While the new FrameworkUtil class can provide access to the framework filter impl (w/o using a BundleContext) access to the bundle DN chain information is not exposed from the framework. So the BundleSignerCondition impl must have private knowledge of the framework impl to access this information. See BundleSignerCondition.getCondition and AdminPermission.SignerWrapper in Eclipse. In the specification process at OSGi we debated this design choice (requiring OSGi defined classes to have hooks into the framework impl) for a very long time. Ultimately this was decided to be the least worst choice. > > >There are other classes where customization is not necessary but will be > >done for performance reasons. e.g FrameworkUtil. > > > > > > I'll take a look at this. Thanks. Classes like FrameworkUtil do not have to be modified. But the OSGi supplied implementation will use a delegation model to call a framework impl supplied class which is connected to the framework impl details. The performance issue is whether always using delegation is replaced by a direct call into the framework impl. So we are fine with framework impls customizing these classes to call directly into the framework impl. See FrameworkUtil.createFilter in Eclipse. > > > Regards, > Alan > > > > BJ Hargrave Senior Software Engineer, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 407 849 9117 Mobile: +1 386 848 3788
