On Mon, Sep 14, 2009 at 11:50 AM, Stuart McCulloch <[email protected]> wrote: > 2009/9/14 Felix Meschberger <[email protected]> > >> Hi, >> >> Neil Bartlett schrieb: >> > On Mon, Sep 14, 2009 at 10:16 AM, Stuart McCulloch <[email protected]> >> wrote: >> >> 2009/9/14 Felix Meschberger <[email protected]> >> >> that's my suspicion... although it is also odd that the fileinstall >> service >> >> tracker >> >> received an event for a service that's not class-loader compatible with >> >> fileinstall >> >> - I would have expected the framework to filter this out and avoid the >> >> exception >> > >> > Is it possible that FileInstall is calling >> > BundleContext.getAllServiceReferences() or ServiceTracker.open(true)? >> >> No, it seems to do ServiceTracker.open(), which is equivalent to >> ServiceTracker.open(false). So this should be save ... >> > > I think there's a bug in our ServiceReference.isAssignableTo > implementation... > > the javadoc for this method states: > > "This method performs the following checks: > > 1. Get the package name from the specified class name. > 2. For the bundle that registered the service referenced by this > ServiceReference (registrant bundle); > find the source for the package. If no source is found then return > true if the registrant bundle is > equal to the specified bundle; otherwise return false. > 3. If the package source of the registrant bundle is equal to the package > source of the specified > bundle then return true; otherwise return false." > > whereas our implementation does: > > // There are three situations that may occur here: > // 1. The requester does not have a wire for the package. > // 2. The provider does not have a wire for the package. > // 3. Both have a wire for the package. > // For case 1, we do not filter the service reference since we > // assume that the bundle is using reflection or that it won't > // use that class at all since it does not import it. For > // case 2, we have to try to load the class from the class > // loader of the service object and then compare the class > // loaders to determine if we should filter the service > // refernce. In case 3, we simply compare the exporting > // modules from the package wiring to determine if we need > // to filter the service reference. > > assume both the provider and requester have no wire for the package > (as happens when a bundle uses it's own export, as in this situation) > > the javadoc says isAssignableTo should return false, because the > provider has no wire and the provider != requester - but we'll return > true because the requester has no wire and we do that check first > > WDYT?
Hm, you might be right. At one point we had a wire for internal packages too (as this was the current state of the draft spec at this time). However, this has changed again and now there is no wire in this case anymore. We will have to look into this. regards, Karl > (ps. I ran the same test on Equinox and no exception occurred) > > Regards >> Felix >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Cheers, Stuart > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
