Your bundle will just be an importer of the packages and using DS to register services. So client bundles of your services need to import the packages from the same source as you: the system bundle. --
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: [email protected] To: "OSGi Developer Mail List" <[email protected]> Date: 2014/10/02 03:06 Subject: Re: [osgi-dev] Faking DS for classpath libraries Sent by: [email protected] Thanks BJ, I was aware of org.osgi.framework.system.packages.extra but I had overlooked org.osgi.framework.bundle.parent=app. It's no problem to set these as I am indeed in charge of launching the framework. Do I also need to take some steps to ensure that the consumers get wired up to my bundle rather than to the system bundle - or maybe that doesn't matter, so long as my bundle is registering the services? Thanks, Chris > First, you will need to get the system bundle to export the necessary > packages. This could be done with the system.classpath.extra launch > property or a framework extension fragment with an Export-Package header. > The latter doesn't require you to be in control of launching the framework > but you probably need to be to get your jar on the CLASSPATH. You will > probably need to make sure that bundle's parent class loader is the > application class loader rather than the default of the boot class loader. > > http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html#FRAMEWORK_BUNDLE_PARENT_APP > But this is also a launch property :-) > > Then your bundle can just import the necessary packages which you arranged > above to be exported and the component description XML you supply will do > the job. As for bnd, just -includeresource your XML and add a > Service-Component header which references the XML. > -- > > 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: [email protected] > To: "'OSGi Developer Mail List'" <[email protected]> > Date: 2014/10/01 15:50 > Subject: [osgi-dev] Faking DS for classpath libraries > Sent by: [email protected] > > > > Hello gang, > > What I am trying to do is a bit underhand, but maybe no more so than some > of the other ideas I've seen discussed here recently ... > > I have a library which is suitable for use as a provider of OSGi services > (because it was conceived that way), but for reasons I really really do > not intend to go into here it is going to have to be loaded on the dear > old linear CLASSPATH (in all-caps, to bring out the retro-flavour of this > concept). Despite this I would like the services to pop up in the service > registry just as they would if the library was loaded as a bundle, so that > other bundles which use DS are able to handle service references in the > same way. > > I can see two ways to do this: 1) write some code which creates instances > of all the service classes and registers them with the framework (in > effect a fake SCR), or 2) create a bundle which contains no code but does > contain some Service-Component XML to "fool" the SCR into doing the work. > Of these the second approach promises to be the more maintainable once I > get it to work, but there are a few bridges to be crossed along the way > ... > > The main issues I have are 1) determining the right combination of > framework properties etc. to get the packages in question to be exported > by the "fake" bundle, and 2) getting bnd[tools] to generate the right > Manifest and Service-Component files so that I can automate the build > process. > > Any ideas? > > Regards, Chris > > > _______________________________________________ > 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
