These changes came about because of support for native libraries in
fragments. Since fragments can attach to multiple hosts in R4.2, the
framework needs to be able to extract multiple copies, one for each host.
The debate was where/how to do this. We could extract into the host
cache directory, which would make it easier to do what you want (i.e.,
all in one directory), but it would complicate cleaning up after
fragments since once it was uninstalled you'd need to remove it from all
current and past host cache directories.
Instead, I decided to extract it into the fragment's cache directory
because when the fragment is uninstalled, everything is cleaned up in
one swoop. Of course, doing so requires the framework to extract into
separate locations to avoid collisions.
Currently, I don't remember the exact details of why we extract the way
we do. If you want to open an issue on this, I will look into it. No
promises about finding a solution, though.
-> richard
On 10/6/09 16:08, Holger Hoffstätte wrote:
Hi,
I just discovered a very odd and - at least for my use case very unhelpful
- change in behaviour of felix from 1.8 to 2.0 concerning native libraries.
You might know about the difficulties of managing libraries with
dependencies. For my project I had pursued the approach of handling Linux
platforms by temporarily copying dependencies to /tmp, loading them by
making the originally loaded JNI library have an RPATH of /tmp, and then
clean up. This is ugly, error-prone, insecure (symlink attack) etc. but
*worked* across all runtimes.
In order to improve this rather ugly hack I now tried to use an RPATH of
"$ORIGIN". This special value will make shared libaries look in the
location of the originating dependency, which is _exactly_ what I want for
bundles. And it works great! There is a slight catch that not all runtimes
unpack bundle libraries eagerly, so the libs have to be referenced in
order to show up in the bundle cache. Works fine too...except on felix 2.0.
For some reason a bundle's libraries are unpacked with any path given in
the NativeCode header (correct and good) but _into another subdirectory_.
This means that three libraries platform/a.so, platform/b.so,
platform/c.so will not end up in a common directory platform/ but rather
in directories platform/0/, platform/1/, platform/2/ and so on - which
totally breaks the great $ORIGIN hack. :(
Is there a good reason why felix would need to do this? Older versions did
not, and neither does equinox (at least not 3.5). I fully realize that the
layout of the bundle cache is "hands off" and an implementation detail,
but at this level I _must_ have some deterministic way of interacting with
the platform. IMHO it is wrong that resources or libraries with common
path prefixes do not actually end up in a common directory - not
technically, but in the "principle of least surprise" way.
Ideas or comments? I can help fix this if necessary.
thanks
Holger
