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
