But if the RSA bundle is used to register its own ServiceFactory class instance then it will fail the check Felix and Equinox have for determining the wacky extender pattern is being used. We only allow for bypassing the frameworks class space consistency checks if we have determined that the service factory fits the extender pattern which I outlined in a previous note. So, no RSA cannot use its own BundleContext in this case. We use a dummy bundle because we want to be sure that no package wires are established for the registering bundle. If a wire is detected by the framework for a service package in question then a class space consistency check will be done no matter what and we do not consider it to fall into this wacky extender ServiceFactory case.
Tom
To: OSGi Developer Mail List <[email protected]>
From: Neil Bartlett <[email protected]>
Sent by: [email protected]
Date: 02/22/2011 02:54PM
Subject: Re: [osgi-dev] Classloader accessibility and ServiceTracker.open(true)
Could I just ask for clarification on the purpose of the dummy bundle. The idea is to avoid importing ANY packages into the bundle that publishes the proxy ServiceFactory... but this could also be achieved by the RSA bundle itself being very careful about its own dependencies. Is that correct?Cheers,Neil_______________________________________________On Tue, Feb 22, 2011 at 8:35 PM, BJ Hargrave <[email protected]> wrote:RSA is not an extender. It does not read metadata from arbitrary bundles and "extend" them by performing actions on their behalf. Don't try and shoehorn RSA into the extender pattern. Tom was just explaining the extender pattern and why the framework handles class space consistency checks for them specially.
> So as I understand it, the RSA use case for the extender is as
> follows (feel free to correct, I may not be stating things correctly):
An RSA impl can take advantage of this support by using 2 bundles: one for defining the implementation of the Service Factory and another for a bundle context to register the service.My example is not a dynamic dummy. It is a static dummy.
> Ok...thanks. I will look into both BJ's dynamic dummy code and thisThis extender support (for avoiding the class space consistency check when the service factory implementation class is defined by a different bundle than the one whose context is used to register the service) is fairly recent so depending upon it will require more recent framework versions.
> approach (a static dummy)...and with some input about how/whether/
> what version Felix support this extender notion...make some decision
> about which way to go (as like I said, we want to be standard/cross-
> framework, as well as support as many versions of the framework
> impls as possible).
>
--
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
_______________________________________________
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
