Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of tjwatson@us.ibm.com designates
 32.97.110.152 as permitted sender)
In-Reply-To: <43BBE501.802@gmail.com>
To: felix-dev@incubator.apache.org
MIME-Version: 1.0
Subject: Re: OSGi, versioning and native code
Message-ID: 
 <OFCA120D55.3A7B4148-ON862570EC.00571930-862570EC.005926AB@us.ibm.com>
From: Thomas Watson <tjwatson@us.ibm.com>
Date: Wed, 4 Jan 2006 10:14:20 -0600
Content-Type: multipart/alternative;
 boundary="=_alternative 005926AA862570EC_="

--=_alternative 005926AA862570EC_=
Content-Type: text/plain; charset="US-ASCII"

Tim Ellison <t.p.ellison@gmail.com> wrote on 01/04/2006 09:08:49 AM:

> 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.

I assume by exports file you mean the bundle manifest file
(META-INF/MANIFEST.MF).  This is where you define your package exports 
and a Bundle-NativeCode header as well as other OSGi define manifest 
headers and directives which the runtime (or Framework) understands.

> 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.

I'm not sure I understand.  In OSGi native code is delivered with the 
bundle as jar entries within the bundle jar.  The Bundle-NativeCode 
header is used to specify the paths to native code and certain directives
which must match for the native library to be used.  For example, 
OS name/version, architecture etc.

This binds the native code directly to the version of the bundle it 
is delivered in.

> So I think coupling the native library and java version info in the
> bundle version number makes sense.

The new selection-filter mechanism provided in OSGi R4 should allow 
you to specify a matching filter for a specific java.version value.
For example:

Bundle-NativeCode: 
 linux_x86/libNative.so;
 osname=Linux; 
 processor=x86;
 selection-filter="(java.version=1.4.*)"

This indicates that the linux_x86/libNative.so library can only be
used on the Linux OS on an x86 processor and the java property 
java.version must match "1.4.*"

> 
> 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...
> 

Since the native library is delivered with each version of the bundle 
there will be two different physical files containing the library.  In 
most implementations of the Framework the native library is extracted to 
disk and the absolute path of the library is returned from the 
bundle's ClassLoader#findLibrary method.

> Any thoughts on loading multiple versions of a bundle containing native
> code?

With standard OSGi this is already possible because each classloader is 
allowed to load different versions of the native library as long as they
are contained in physically different file locations.

But I'm pretty sure Harmony is not a "standard" OSGi Framework, right? 
I imagine you are using OSGi bundle manifest headers to specify 
dependencies between the different class libraries, but at runtime you 
are actually loading all the code with the same classloader (the boot 
classloader).  If the same classloader is used for each class library 
version then you will definately run into issues trying to load different 
versions of the same library name.  But wait, you would run into the 
same problem loading different version of the same class with the same
classloader.  So you must be using different classloaders for each 
version of the class library, right?  Maybe you can explain the 
Harmony runtime and how it relates to the OSGi runtime.

> 
> Thanks
> Tim
> 
> -- 
> 
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.

Regards

Tom.

--=_alternative 005926AA862570EC_=--