felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: OSGi, versioning and native code
Date Wed, 04 Jan 2006 17:15:07 GMT
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message