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: > > > 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): > > 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. > > 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. > > > Ok...thanks. I will look into both BJ's dynamic dummy code and this > > My example is not a dynamic dummy. It is a static dummy. > > > 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). > > > > This 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. > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>* > **[email protected]* <[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
