osgi NoClassDefFoundError-罐子目录

Question

我有一个包含大量jar文件的目录。更具体地说：Apache Spark。现在，我想使用Spark库编写Java / osgi程序。最好的方法是什么？

一种方法是将整个200MB捆绑到osgi捆绑包中。结果将是一个巨大的插件，无论如何都具有与服务器上相同的jar文件，并且在最坏的情况下与服务器的Spark版本不兼容。

另一种选择是将所有200MB的jar文件添加到项目的lib文件夹中，并将其视为嵌入式库。与上述相同。

唯一的选择是在运行时修改类加载器，将Spark的jar目录添加到类路径。那也不好。

但是坦率地说，我认为这个用例超出了osgi应该做的事情。 osgi用于控制依赖关系，包括版本，我要求使用已经安装的版本。矛盾，不是吗？

您有建议吗？我确实忽略了什么？

谢谢！

Answer 1

OSGi与软件工程有关。关于验证编译时依赖性是否与兼容的运行时依赖性相匹配。当遵循（简单）规则时，与没有OSGi的情况相比，您得到的系统要可靠得多，因为像许多非OSGi项目一样，没有“假设”任何东西。

不幸的是，这意味着您需要正确获取元数据。尽管现在有大量代码具有OSGi元数据，但人们自然倾向于捷径。那一刻，你是两全其美的。您没有获得很多好处，但是您仍然付出了代价。 OSGi是一项非常出色的“全程”技术，选择某些零件几乎没有好处。

如果遇到您的问题，我将分析Spark所需的代码，看看是否可以将其转变为许多干净，紧密和未耦合的服务API。我将针对这些API编写代码。在OSGi运行时中，我将使用自己的依赖项。我将在框架外部注册我的Spark服务实现，以便Spark类空间和OSGi类空间是分开的。但是，这并非易事，因为太多的API倾向于泄漏实现细节和实现依赖性。

根据我的经验，尝试移植不是为具有200 Mb依赖项的OSGi设计的开源项目是一项主要任务。尝试将安全性添加到未从头开始设计的程序中以考虑到安全性，这非常相似。

Answer 2

很久以前，我试图从OSGi调用spark，并放弃了。 Spark对于依赖项是一团糟，即使您将依赖项排序出去，仍然是一个问题，即spark或其依赖项中的哪一个会进行类加载技巧。因此，我认为尝试在OSGi中运行Spark不值得。

也许您可以创建一个微服务，该微服务可以在提供Spark作为其他服务的基础上提供满足您的需求的api。因此spark在OSGi进程之外运行。