2009/4/13 Jae Woo Lee <[email protected]> > If you use the new framework launching API (in 4.2 spec draft and >> implemented in the recent Equinox and Felix builds), you will have a Bundle >> and BundleContext for the framework (system bundle) you created. You can >> then register/use services to communicate with bundles installed in the >> framework. This is a far better idea than trying to directly interact with >> implementation classes in bundles. >> > > Thank you so much for the info. Framework launching API seems to be just > what I need. > > You can either >> (a) have your code register a service which bundles can use(call) to get >> information from the C code. >> > > I am working on this and it seems promising. At first I couldn't figure > out how to make a non-bundle interface available to a bundle, but I found a > property called "org.osgi.framework.system.packages.extra" which seems to > add packages to framework namespace. > >> (b) have bundles register services which the C code can get and call with >> information >> > > Actually I tried this first, but could not get it working. > > I have a Java code that launches OSGi using the launching API. It then > installs a bundle that registers a service. It then tries to get that > service instance from the framework's BundleContext. I get the service > instance when I call context.getService(ref), but I can't call a method on > it because I cannot cast it to the service interface. The service interface > that the service object implements comes from a bundle class loader, so it's > not accessible to my non-OSGi launcher code. >
is the service interface available on the launcher's classpath? if so then you could use "org.osgi.framework.system.packages.extra" (available in recent builds) to add the package containing the service interface to the system bundle exports - then as long as the bundle providing the service imports this package everyone should see the same class (ie. the one from the launcher's classpath) alternatively you could use the "org.osgi.framework.bootdelegation" property to get everyone to delegate to the boot classloader for this package, which is useful for legacy code but has drawbacks - there's only one version of the package and you have to remove any imports of the package from other bundles, otherwise they won't resolve because no-one exports the package (ie. it is provided by classic style classloader delegation) if neither of these work (or perhaps you can't see the service interface from the launcher code) then reflection is the last resort Is there a way to get around this? > >> You can even do a combination of both. >> -- >> BJ Hargrave >> >> Thanks again for the tips. Really appreciate it. > > - Jae > -- Cheers, Stuart
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
