You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rob Walker <ro...@ascert.com> on 2007/10/26 17:35:49 UTC
Possible Felix bacwards compatibility issue
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;
processor=IA64N
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
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Possible Felix bacwards compatibility issue
Posted by Rob Walker <ro...@ascert.com>.
Cheers - have done this.
Have a great weekend!
- Rob
Richard S. Hall wrote:
> I agree that it sounds like an issue...create a JIRA issue against the
> framework and I will try to look into it.
>
> -> richard
>
> Rob Walker wrote:
>> 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;
>> processor=IA64N
>>
>> 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
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Possible Felix bacwards compatibility issue
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I agree that it sounds like an issue...create a JIRA issue against the
framework and I will try to look into it.
-> richard
Rob Walker wrote:
> 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;
> processor=IA64N
>
> 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
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>
>