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

Reply via email to