Tim Ellison <[EMAIL PROTECTED]> 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
> > [EMAIL PROTECTED]
> > Office: +1 407 849 9117 Mobile: +1 386 848 3788
> >
> >
> >
> > Tim Ellison <[EMAIL PROTECTED]>
> > 2006-01-04 10:08 AM
> > Please respond to
> > [email protected]
> >
> >
> > To
> > [email protected]
> > 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 ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788
