felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Walker <r...@ascert.com>
Subject Possible Felix bacwards compatibility issue
Date Fri, 26 Oct 2007 15:35:49 GMT
We have a bundle that includes native code. The native code is only 
needed/used on some platforms, and hence the manifest doesn't list every 
platform used e.g.

    Bundle-NativeCode: /platlib.dll; osname=Windows NT; osname=Windows
    2000; osname=Windows 2003; osname=Windows XP; processor=x86,
    /libplatlib.so; osname=Linux; processor=x86; osname=NONSTOP_KERNEL;

Previous versions of Felix/Oscar were fine with this - you only got an 
error thrown when you tried to actually use native classes on a platform 
that was not declared in the Manifest.

It seems now that this breaks during Manifest parsing, meaning our app 
won't load on say Solaris, even though we don't actually need the native 
libs on that platform:

org.osgi.framework.BundleException: Unable to select a native library clause.
        at org.apache.felix.framework.util.manifestparser.ManifestParser.getSelectedLibraryClause(ManifestParser.java:349)
        at org.apache.felix.framework.util.manifestparser.ManifestParser.getLibraries(ManifestParser.java:306)
        at org.apache.felix.framework.Felix.createModule(Felix.java:3337)
        at org.apache.felix.framework.Felix.createBundleInfo(Felix.java:3263)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2224)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2138)
        at org.apache.felix.framework.Felix.processAutoProperties(Felix.java:3606)
        at org.apache.felix.framework.Felix.start(Felix.java:803)
        at com.ascert.vt.launch.VtLauncher.a(VtLauncher.java:142)
        at com.ascert.vt.launch.VtLauncher.a(VtLauncher.java:102)
        at com.ascert.vt.launch.VtLauncher.a(VtLauncher.java:224)
        at com.ascert.vt.launch.VtLauncher.main(VtLauncher.java:210)

It doesn't seem right that Manifest parser should object to this and 
throw a fatal error - just because a native lib is not provided for the 
current platform does not mean it will be actually needed, and surely 
the parser's job isn't to make such decisions. At the point a missing 
native lib is needed and missing would seem to be the more valid place 
to throw an error, which I think is how it used to work.

One workaround would be to split out Winx86 libs into separate bundles, 
but that sort of defeats the elegant way OSGi handles platform dependencies.

Any other suggestions?

-- Rob

Ascert - Taking systems to the Edge
+44 (0)20 7488 3470

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message