Osgi将与bundle内的本机代码不匹配

Question

我正在尝试使用一个具有本地代码依赖性的Eclipse插件。这些依赖关系总是无法解析，所以这个插件永远不会被OSGI加载。

MANIFEST.MF

    Manifest-Version: 1.0
    Bundle-ManifestVersion: 2
    Bundle-Name: PROS Cortex Flash Utility
    Bundle-SymbolicName: com.purduesigbots.vexflash; singleton:=true
    Bundle-Version: 1.0.0.6
    Bundle-Activator: com.purduesigbots.vexflash.Activator
    Bundle-Vendor: Purdue ACM SIG BOTS
    Require-Bundle: org.eclipse.ui,org.eclipse.core.runtime,org.eclipse.co
     re.resources,org.eclipse.ui.ide;bundle-version="3.7.0",org.eclipse.de
     bug.ui;bundle-version="3.7.0"
    Bundle-RequiredExecutionEnvironment: JavaSE-1.6
    Bundle-ActivationPolicy: lazy
    Bundle-NativeCode:
      /libs/windows/jSSC-2.6_x86_64.dll;
      osname=win32; processor=x86_64, *
    Bundle-ClassPath: .,jna.jar,platform.jar

dll的路径是bundle jar中的/libs/windows/jSSC-2.6_x86_64.dll。我尝试了很多不同的方法来尝试加载本机，但都没有成功。

如何让OSGI加载本机库？我在Windows 10上运行JRE 8 64位。

编辑：

我修改了MANIFEST.MF，使其工作

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: PROS Cortex Flash Utility
Bundle-SymbolicName: com.purduesigbots.vexflash; singleton:=true
Bundle-Version: 1.0.0.6
Bundle-Activator: com.purduesigbots.vexflash.Activator
Bundle-Vendor: Purdue ACM SIG BOTS
Require-Bundle: org.eclipse.ui,org.eclipse.core.runtime,org.eclipse.co
 re.resources,org.eclipse.ui.ide;bundle-version="3.7.0",org.eclipse.de
 bug.ui;bundle-version="3.7.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Bundle-NativeCode:
#The OS name is not in OS aliases for OSGI, so the full name must be used
  /libs/windows/jSSC-2.6_x86_64.dll;
  osname=win32; osname="Windows 10"; processor=x86_64
Bundle-ClassPath: .,jna.jar,platform.jar

Answer 1

在我的案例中，有一个RCP应用程序在将JRE从1.8.0.5更新到1.8.0.162后，在DLL上出现不满足链接错误而停止。经过一番搜索，我发现在Windows 10下使用Bundle NativeCode指令中的win32别名时，存在两个错误，一个在Java中，另一个在OSGi中，它们相互抵消。它在更新之前工作的原因是，Java会恢复到默认值，以防它不知道Windows返回的版本。OSGi知道这种回退，并与win32别名相匹配。现在更新Java意味着不再使用默认值，而是使用"Windows 10"。然而，在Luna之前的OSGi版本不知道Windows10，因此与win32别名不匹配。

我采用的解决方法是，相应地覆盖org.osgi.framework.os.name属性，这是可行的，因为该应用程序没有其他目标：

-Dorg.osgi.framework.os.name=win32

在大多数情况下，更好的解决方案是将OSGi更新到至少3.10.0。

当然，像作者一样，将"Windows 10"作为额外的os.name添加到清单中，效果也很好。我决定不这么做，因为我在依赖关系中有几个这样的原生二进制文件，它们不在我的控制之下。