OSGI bundle中Bundle-Classpath的预期用例是什么
假设我正在创建一个OSGI包，它将部署在其他包的生态系统中。我正在处理的包需要一些其他包，但它们不在此生态系统中加载/导出，并且我无法控制生态系统导出什么。在这种情况下，我可以将这些bundle放入某个目录（比如'lib')，该目录成为bundle的一部分。还应该从Bundle-Classpath引用这些包，因此可以加载它们。
- 这是一个正确的Bundle-Classpath用例吗？
- 这些附加包是否也会加载到OSGI容器中，并且它们导出的包是否可用于其他包？
共有1个答案
bundle-classpath旨在将依赖项包含在包中，以便可以独立部署包。
让我们举个例子。假设我的bundle中的代码使用了一个库，例如Google Guava。我有两种包装我的包的选择：
>
只需创建我的bundle,其中只包含我自己的代码。bundle现在将有import-package语句声明对Guava的依赖关系，任何想要将我的bundle部署到其应用程序中的人也必须部署Guava。
选项2的一个更严重的问题是，库的所有依赖项现在也变成了我的依赖项。实际上，Guava是Java库中少有的没有依赖项的例子...但许多其他Java库拖入了一个巨大的可传递依赖关系树。如果您在Hibernate中使用这种方法，那么您自己的bundle也将具有较大的依赖项集。这变得非常难看，非常快。
因此，您应该谨慎，不要过度使用bundle-classpath/embed-dependency。只有当依赖关系很小，并且没有可传递的依赖关系，并且(b)您的包将库用作内部实现细节，即它不是您的公共API的一部分时，才应该考虑使用它。
更新
-
问题内容： 我在kotlin-stdlib中遇到了注解，我想知道它是做什么用的，但是不幸的是，它没有记录。（UPD：那时） 据我了解，将其应用于程序元素会将修饰符添加到相应的字节码元素中。结果，该元素在Java中变得不可见： Java代码中的某处： 但是相同的元素在Kotlin代码中仍然可见： 隐藏来自非Kotlin来源的声明是否有效使用？它是预期用途吗？还有哪些其他合适的用例？ 由于从Java隐
-
问题内容： 我们正在重用一个使用spring java- config（使用@Configuration）定义其bean的项目，并且在一个此类中有一个init方法。 这里的预期行为是什么？何时调用此方法？关于豆子，那就是。即，此方法的行为是否完全像配置类是Bean一样（实际上是一个吗？） 我们观察到的是，根据操作系统的不同，可以在初始化进入配置类的Bean之前调用它，从而最终导致不完全依赖项的工作
-
我在Spring Boot项目中使用Resilience4J调用REST客户机，如下所示： 看到示例中包含了一个回退方法，我决定添加它，尽管我并不真的想调用不同的方法，我只想再次调用我的原始方法。 不管怎样，我指定了一个回落： 现在，我看到回退方法被重试，但是每次都会抛出HttpServerErrorException，这意味着使用者将收到一个异常作为对其调用的响应。 谢谢
-
问题内容： 我正在处理一些Spring XML配置文件，有时使用和有时。两者之间有区别吗？还是领先的可选/隐含/冗余？ 问题答案： 我认为这两者之间没有任何区别。您将看到的最大区别是相对路径和类路径位置上的* 这是Spring Resources的节选，请参见4.7.2.2节 Classpath *： “ classpath ：”前缀也可以与其余位置路径中的PathMatcher模式结合使用，例如
-
本文向大家介绍Android 中为什么要用Fragment.setArguments(Bundle bundle)来传递参数，包括了Android 中为什么要用Fragment.setArguments(Bundle bundle)来传递参数的使用技巧和注意事项，需要的朋友参考一下 Fragment在Android3.0开始提供，并且在兼容包中也提供了Fragment特性的支持。Fragment的