You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Tim Ellison <t....@gmail.com> on 2006/01/04 16:08:49 UTC
OSGi, versioning and native code
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.
Re: OSGi, versioning and native code
Posted by Tim Ellison <t....@gmail.com>.
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.
Re: OSGi, versioning and native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Bear in mind that I may not totally understand the situation you are
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?
-> 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
>
>
Re: OSGi, versioning and native code
Posted by Tim Ellison <t....@gmail.com>.
Thomas Watson wrote:
> Tim Ellison <t....@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.
No, I really mean the exports file (.def/.exp) for functions 'exposed'
from the native library, be they JNI functions or 'regular' C functions.
>>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.
Right, so I think it makes sense to forego the platform's solution (such
as an ELF version script [1]) in this case, and reflect any changes to
the exported C functions as a change in the bundle version number; i.e.
treat the Java code and native code combined as the bundle.
>>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.*"
Understood.
>>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.
I see that now thanks to BJ's explanation.
> 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.
We are planning on pulling a few stunts that are out of scope of this
thread, so for now it is fair to assume that my question relates to
normal application code.
Regards,
Tim
[1]
http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: OSGi, versioning and native code
Posted by Thomas Watson <tj...@us.ibm.com>.
Tim Ellison <t....@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.
Re: OSGi, versioning and native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Tim Ellison wrote:
> Looking back at the msdn doc, it appears to depend upon the version of
> Windows. On 'big' windows (Windows 95/98/NT/XP etc.) then it appears
> that the LoadLibrary *does* consider the path as you say [1]; but for
> Windows CE it appears that the file basename must be different (see [2]
> -- the paragraph starting "Two different modules cannot...").
Interesting. Something we will have to think about how to work around in
Felix, perhaps...good thing not too many people use Windows. ;-)
-> richard
Re: OSGi, versioning and native code
Posted by Tim Ellison <t....@gmail.com>.
Richard S. Hall wrote:
> Tim Ellison wrote:
>
>>> The OSGi framework must process the
>>> Bundle-NativeCode header to make the selected libraries available at
>>> some bundle unique location so that if each bundle contains
>>> libfoo.so, the absolute path for each bundle's libfoo.so is unique.
>>
>> Not only path, but also filename I would assume, right?
>> On windows a call to LoadLibrary with \\foo\mylib.dll followed by a call
>> to LoadLibrary with \\bar\mylib.dll will simply result in reloading
>> \\foo\mylib.dll. So will the framework mange the filename too to allow
>> for multiple versions of my bundle's natives to be active concurrently?
>
> Are you sure? I don't think this is the case, I think it is the complete
> path. I did testing on this before for Oscar and I only had to change
> the path, unless I missed something.
Looking back at the msdn doc, it appears to depend upon the version of
Windows. On 'big' windows (Windows 95/98/NT/XP etc.) then it appears
that the LoadLibrary *does* consider the path as you say [1]; but for
Windows CE it appears that the file basename must be different (see [2]
-- the paragraph starting "Two different modules cannot...").
[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp
[2]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcekernl/html/_wcesdk_Win32_LoadLibrary.asp
Regards,
Tim
>> As a bonus question: Is there any support for native to native calls?
>>
>
> No.
>
>> Assume I have a bundle that only contains library files, with a manifest
>> to get the platform deploy right, versioning etc.. As I've now learnt,
>> the framework will put the right library into some unique location that
>> I'm not privy to; so I assume I can *only* load it via the framework
>> (System.loadLibrary()) by calling back into java :-( , and then I need
>> to get a handle to that library instance so I can GetProcAddress/dlsym a
>> function in that library, and of course there is no API way to get that
>> handle :-( . Is that right, am I out of luck for native->native calls
>> between bundles?
>
> Yes, you are out of luck.
>
>
> -> richard
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: OSGi, versioning and native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Tim Ellison wrote:
>> The OSGi framework must process the
>> Bundle-NativeCode header to make the selected libraries available at some
>> bundle unique location so that if each bundle contains libfoo.so, the
>> absolute path for each bundle's libfoo.so is unique.
>>
>
> Not only path, but also filename I would assume, right?
> On windows a call to LoadLibrary with \\foo\mylib.dll followed by a call
> to LoadLibrary with \\bar\mylib.dll will simply result in reloading
> \\foo\mylib.dll. So will the framework mange the filename too to allow
> for multiple versions of my bundle's natives to be active concurrently?
>
Are you sure? I don't think this is the case, I think it is the complete
path. I did testing on this before for Oscar and I only had to change
the path, unless I missed something.
> As a bonus question: Is there any support for native to native calls?
>
No.
> Assume I have a bundle that only contains library files, with a manifest
> to get the platform deploy right, versioning etc.. As I've now learnt,
> the framework will put the right library into some unique location that
> I'm not privy to; so I assume I can *only* load it via the framework
> (System.loadLibrary()) by calling back into java :-( , and then I need
> to get a handle to that library instance so I can GetProcAddress/dlsym a
> function in that library, and of course there is no API way to get that
> handle :-( . Is that right, am I out of luck for native->native calls
> between bundles?
>
Yes, you are out of luck.
-> richard
Re: OSGi, versioning and native code
Posted by BJ Hargrave <ha...@us.ibm.com>.
Tim Ellison <t....@gmail.com> wrote on 2006-01-05 05:39:57 AM:
> But in this example the "db2e" is not under version control, so multiple
> concurrently active versions of the "db2ejdbc" bundle are required to
> agree on a common db2e library.
>
> Even if you put the db2e code into it's own bundle, you couldn't
> differentiate between the two versions when making a C call from db2jdbc
> to db2e (because you can't get a handle to the library version you want)
> unless you rely upon the loadLibrary() call to open the library for you.
>
> I think the moral to this story is that the bundle versioning bottoms
> out at the loadLibrary() call, beyond that you should probably revert to
> deploying the platform libraries outside the framework, and using the
> platform's version control where it exists.
Probably wise. :-)
>
> Regards,
> Tim
>
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
Re: OSGi, versioning and native code
Posted by Tim Ellison <t....@gmail.com>.
BJ Hargrave wrote:
> Tim Ellison <t....@gmail.com> wrote on 2006-01-04 12:00:34 PM:
>
>
>>BJ Hargrave wrote:
>>
>>>Native code loading is associated with both (a) the class loader and
>
> (b)
>
>>>the absolute file name. The class loader gets to map the requested lib
>
>
>>>name onto an absolute file name via a call made to
>>>ClassLoader.findLibrary.
>>
>>Cool, that's what I was thinking.
>>
>>
>>>The OSGi framework must process the
>>>Bundle-NativeCode header to make the selected libraries available at
>
> some
>
>>>bundle unique location so that if each bundle contains libfoo.so, the
>>>absolute path for each bundle's libfoo.so is unique.
>>
>>Not only path, but also filename I would assume, right?
>>On windows a call to LoadLibrary with \\foo\mylib.dll followed by a call
>>to LoadLibrary with \\bar\mylib.dll will simply result in reloading
>>\\foo\mylib.dll. So will the framework mange the filename too to allow
>>for multiple versions of my bundle's natives to be active concurrently?
>
> Well the typicall usage is System.loadLibrary("mylib"). The VM will then
> call ClassLoader.findLibrary("mylib"). The implementation of findLibrary
> will call System.mapLibraryName("mylib") which will return mylib.dll for
> Windows or libmylib.so for unix flavors, etc. The implementation will then
> take the mapped name and look for the native lib in the place where the
> framework impl stashed the native libs selected by the Bundle-NativeCode
> header.
>
> It will also attempt to find the unmapped name if the mapped name cannot
> be found to compensate for folks who did not properly name things :-)
Understood. My observation was that, AIUI, the stashed file basename
has to be different too, as described in the response to Richard.
>>>Furthermore, the VM only allows a native library at a given absolute
>
> path
>
>>>to be loaded only once. This is why the OSGi framework must make sure
>
> that
>
>>>bundles have unique locations for their native libs. It also means
>
> that
>
>>>the each revision of a bundle (for this discussion, when a bundle is
>>>updated you have a new revision) needs to place its native libs in a
>>>unique location. However, we are still left with some issues around
>>>refreshPackages which results in a new class loader for the bundle but
>
>
>>>does not change the absolute paths of the bundle native libs.
>>>
>>>For more details read section 3.9 (and 3.9.1 in particular) of the R4
>
> Core
>
>>>spec.
>>
>>I've read it, but it's not as clear as the explanation you just gave :-)
>>Thanks.
>>
>>As a bonus question: Is there any support for native to native calls?
>>Assume I have a bundle that only contains library files, with a manifest
>>to get the platform deploy right, versioning etc.. As I've now learnt,
>>the framework will put the right library into some unique location that
>>I'm not privy to; so I assume I can *only* load it via the framework
>>(System.loadLibrary()) by calling back into java :-( , and then I need
>>to get a handle to that library instance so I can GetProcAddress/dlsym a
>>function in that library, and of course there is no API way to get that
>>handle :-( . Is that right, am I out of luck for native->native calls
>>between bundles?
>
> There is no specific support within the framework, but you can deal with
> this from the Java code. Let me give a specific example using IBM DB2e (an
> embedded database). The db engine is a native lib ("db2e"). The JDBC code
> is another native lib containing JNI ("db2ejdbc"). When packaged in a
> bundle, the bundle needs to access the JNI code so it must do
> System.loadLibrary("db2ejdbc"). But the JNI native lib has native links to
> the db engine native code. To work with this, the bundle must first call
> System.loadLibrary("db2e") before calling System.loadLibrary("db2ejdbc").
> The VM will load the db engine into the process before the JNI lib so when
> the JNI lib needs to access the db engine code, it is already loaded. (I
> have no idea how this technique will respond under bundle updates/etc.
> since the reference from the JNI lib to the db engine is outside the
> naming influence of the java runtime.)
But in this example the "db2e" is not under version control, so multiple
concurrently active versions of the "db2ejdbc" bundle are required to
agree on a common db2e library.
Even if you put the db2e code into it's own bundle, you couldn't
differentiate between the two versions when making a C call from db2jdbc
to db2e (because you can't get a handle to the library version you want)
unless you rely upon the loadLibrary() call to open the library for you.
I think the moral to this story is that the bundle versioning bottoms
out at the loadLibrary() call, beyond that you should probably revert to
deploying the platform libraries outside the framework, and using the
platform's version control where it exists.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: OSGi, versioning and native code
Posted by BJ Hargrave <ha...@us.ibm.com>.
Tim Ellison <t....@gmail.com> wrote on 2006-01-04 12:00:34 PM:
> BJ Hargrave wrote:
> > Native code loading is associated with both (a) the class loader and
(b)
> > the absolute file name. The class loader gets to map the requested lib
> > name onto an absolute file name via a call made to
> > ClassLoader.findLibrary.
>
> Cool, that's what I was thinking.
>
> > The OSGi framework must process the
> > Bundle-NativeCode header to make the selected libraries available at
some
> > bundle unique location so that if each bundle contains libfoo.so, the
> > absolute path for each bundle's libfoo.so is unique.
>
> Not only path, but also filename I would assume, right?
> On windows a call to LoadLibrary with \\foo\mylib.dll followed by a call
> to LoadLibrary with \\bar\mylib.dll will simply result in reloading
> \\foo\mylib.dll. So will the framework mange the filename too to allow
> for multiple versions of my bundle's natives to be active concurrently?
Well the typicall usage is System.loadLibrary("mylib"). The VM will then
call ClassLoader.findLibrary("mylib"). The implementation of findLibrary
will call System.mapLibraryName("mylib") which will return mylib.dll for
Windows or libmylib.so for unix flavors, etc. The implementation will then
take the mapped name and look for the native lib in the place where the
framework impl stashed the native libs selected by the Bundle-NativeCode
header.
It will also attempt to find the unmapped name if the mapped name cannot
be found to compensate for folks who did not properly name things :-)
>
> > Furthermore, the VM only allows a native library at a given absolute
path
> > to be loaded only once. This is why the OSGi framework must make sure
that
> > bundles have unique locations for their native libs. It also means
that
> > the each revision of a bundle (for this discussion, when a bundle is
> > updated you have a new revision) needs to place its native libs in a
> > unique location. However, we are still left with some issues around
> > refreshPackages which results in a new class loader for the bundle but
> > does not change the absolute paths of the bundle native libs.
> >
> > For more details read section 3.9 (and 3.9.1 in particular) of the R4
Core
> > spec.
>
> I've read it, but it's not as clear as the explanation you just gave :-)
> Thanks.
>
> As a bonus question: Is there any support for native to native calls?
> Assume I have a bundle that only contains library files, with a manifest
> to get the platform deploy right, versioning etc.. As I've now learnt,
> the framework will put the right library into some unique location that
> I'm not privy to; so I assume I can *only* load it via the framework
> (System.loadLibrary()) by calling back into java :-( , and then I need
> to get a handle to that library instance so I can GetProcAddress/dlsym a
> function in that library, and of course there is no API way to get that
> handle :-( . Is that right, am I out of luck for native->native calls
> between bundles?
There is no specific support within the framework, but you can deal with
this from the Java code. Let me give a specific example using IBM DB2e (an
embedded database). The db engine is a native lib ("db2e"). The JDBC code
is another native lib containing JNI ("db2ejdbc"). When packaged in a
bundle, the bundle needs to access the JNI code so it must do
System.loadLibrary("db2ejdbc"). But the JNI native lib has native links to
the db engine native code. To work with this, the bundle must first call
System.loadLibrary("db2e") before calling System.loadLibrary("db2ejdbc").
The VM will load the db engine into the process before the JNI lib so when
the JNI lib needs to access the db engine code, it is already loaded. (I
have no idea how this technique will respond under bundle updates/etc.
since the reference from the JNI lib to the db engine is outside the
naming influence of the java runtime.)
>
> Thanks
> Tim
>
>
> > BJ Hargrave
> > Senior Technical Staff Member, IBM
> > OSGi Fellow and CTO of the OSGi Alliance
> > hargrave@us.ibm.com
> > Office: +1 407 849 9117 Mobile: +1 386 848 3788
> >
> >
> >
> > Tim Ellison <t....@gmail.com>
> > 2006-01-04 10:08 AM
> > Please respond to
> > felix-dev@incubator.apache.org
> >
> >
> > To
> > felix-dev@incubator.apache.org
> > cc
> >
> > Subject
> > OSGi, versioning and native code
> >
> >
> >
> >
> >
> >
> > 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.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Re: OSGi, versioning and native code
Posted by Tim Ellison <t....@gmail.com>.
BJ Hargrave wrote:
> Native code loading is associated with both (a) the class loader and (b)
> the absolute file name. The class loader gets to map the requested lib
> name onto an absolute file name via a call made to
> ClassLoader.findLibrary.
Cool, that's what I was thinking.
> The OSGi framework must process the
> Bundle-NativeCode header to make the selected libraries available at some
> bundle unique location so that if each bundle contains libfoo.so, the
> absolute path for each bundle's libfoo.so is unique.
Not only path, but also filename I would assume, right?
On windows a call to LoadLibrary with \\foo\mylib.dll followed by a call
to LoadLibrary with \\bar\mylib.dll will simply result in reloading
\\foo\mylib.dll. So will the framework mange the filename too to allow
for multiple versions of my bundle's natives to be active concurrently?
> Furthermore, the VM only allows a native library at a given absolute path
> to be loaded only once. This is why the OSGi framework must make sure that
> bundles have unique locations for their native libs. It also means that
> the each revision of a bundle (for this discussion, when a bundle is
> updated you have a new revision) needs to place its native libs in a
> unique location. However, we are still left with some issues around
> refreshPackages which results in a new class loader for the bundle but
> does not change the absolute paths of the bundle native libs.
>
> For more details read section 3.9 (and 3.9.1 in particular) of the R4 Core
> spec.
I've read it, but it's not as clear as the explanation you just gave :-)
Thanks.
As a bonus question: Is there any support for native to native calls?
Assume I have a bundle that only contains library files, with a manifest
to get the platform deploy right, versioning etc.. As I've now learnt,
the framework will put the right library into some unique location that
I'm not privy to; so I assume I can *only* load it via the framework
(System.loadLibrary()) by calling back into java :-( , and then I need
to get a handle to that library instance so I can GetProcAddress/dlsym a
function in that library, and of course there is no API way to get that
handle :-( . Is that right, am I out of luck for native->native calls
between bundles?
Thanks
Tim
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@us.ibm.com
> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>
>
>
> Tim Ellison <t....@gmail.com>
> 2006-01-04 10:08 AM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> OSGi, versioning and native code
>
>
>
>
>
>
> 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.
Re: OSGi, versioning and native code
Posted by BJ Hargrave <ha...@us.ibm.com>.
Native code loading is associated with both (a) the class loader and (b)
the absolute file name. The class loader gets to map the requested lib
name onto an absolute file name via a call made to
ClassLoader.findLibrary. The OSGi framework must process the
Bundle-NativeCode header to make the selected libraries available at some
bundle unique location so that if each bundle contains libfoo.so, the
absolute path for each bundle's libfoo.so is unique.
Furthermore, the VM only allows a native library at a given absolute path
to be loaded only once. This is why the OSGi framework must make sure that
bundles have unique locations for their native libs. It also means that
the each revision of a bundle (for this discussion, when a bundle is
updated you have a new revision) needs to place its native libs in a
unique location. However, we are still left with some issues around
refreshPackages which results in a new class loader for the bundle but
does not change the absolute paths of the bundle native libs.
For more details read section 3.9 (and 3.9.1 in particular) of the R4 Core
spec.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Tim Ellison <t....@gmail.com>
2006-01-04 10:08 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
OSGi, versioning and native code
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.