Richard S. Hall wrote: > Bear in mind that I may not totally understand the situation you are > describing... :-)
Likewise ;-) (I may not understand everything that I'm describing) > In order for the OSGi framework to resolve a given bundle's native > libraries, they must be extracted from the bundle's JAR file. The > framework stores these extracted native libraries in some > implementation-dependent way. Most frameworks will extract the native > libraries for individual bundles in such a way that they do not conflict > with each other (i.e., they are stored in different places on the disk). > > The class loader associated with a given bundle resolves native library > references to the native libraries extracted from the given bundle only. > Since all native libraries are in different locations, they can all be > loaded simultaneously (assuming that there are not hard conflicts > between different versions of the same native library). > > This should work in all OSGi frameworks. Does that answer some of your > questions? Understood (now), the framework will mangle the native library path to keep them separated. Provided the base file name is different too (as I described in my response to BJ) then I'm happy with the Java <-> C story. Thanks Tim > -> richard > > Tim Ellison wrote: > >> In Harmony we are splitting up the implementation of the Java class >> library itself into components, and using OSGi for guiding principles. >> >> In the java code world, we have got the manifest that defines the >> versioned package imports and exports from a module permitting multiple >> bundle versions to be active at once. This is good. >> >> The bit I don't understand is how this model extends to *native* code at >> runtime. The native runtime interface is defined by the exports file. >> However, if we rely on native library versioning independently of bundle >> versioning we could get into a situation where the runtime can't solve >> the bundle dependencies and the library dependencies at the same time. >> So I think coupling the native library and java version info in the >> bundle version number makes sense. >> >> So then the question I have is how to deal with natives for multiple >> versions of a given bundle at runtime? They need to be in different >> named files on windows to reloading a single DLL, so how is that related >> to the bundle version number? Does the bundle activator augment the >> load library with a versioned library name? or... >> >> Any thoughts on loading multiple versions of a bundle containing native >> code? >> >> Thanks >> Tim >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
