osgi 包导出类，但仍然拾取类路径中的类
我正在尝试使用使用 osgi 包并导出一些类的 web 应用程序来部署 Ear。这是在应用程序服务器中。 该捆绑包导出从类 B 派生的类 A。ClassB 实际上是该捆绑包决定提供的第 3 方开源类。问题是我的耳朵在耳朵的 lib 目录中还有另一个版本的 classB 。
在尝试部署应用程序时，我收到一个奇怪的错误，类 A 是从 osgi 包 jar 加载的，但由于类 B 是从 Ear 的 lib 目录而不是从 osgi 包加载的，即使它在那里。
这会导致错误，因为 classA 期望其基类中存在某些行为，但实际上并不存在，因为 classB 是从包外部加载的。
我不知道如何解决这个问题——这是我第一次遇到 osgi，我有点担心这可能比类路径地狱更糟糕，特别是对于需要与 osgi 的一部分集成而不是 osgi 的一部分集成的应用程序。
I am trying to use deploy an ear with a webapp that uses an osgi bundle and exports some classes. This is in an appserver.
the bundle exports class A which derivbes from class B. ClassB is really a 3rd party opensource class, which the bundle has decided to provide. The problem is my ear also has another version of classB in the ear's lib directory.
On attempting to deploy the application, I am getting a strange error, the class A is loaded from osgi bundle jar, but since classB is loaded from the ear's lib directory and not from the osgi bundle, even though its there.
This is leading to errors resulting from the classA expecting some behavior to be there in its baseclass, but in reality does not exist because classB is loaded form outside the bundle.
I am not sure how to fix this- this is my first encounter with osgi and i am a little concerned that this could be worse than classpath hell, especially for apps that require integration with parts of it being osgi and parts of it not.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我知道人们正在尝试混合 Java EE 和 OSGi 堆栈，但我认为这是导致问题的根源。他们对类加载器的工作方式都有自己的期望，并且让他们合作可能是一个问题。
如果您必须这样做，您可以通过将尽可能多的 Web 应用程序放入 osgi 容器中来让自己的生活更轻松。或者，找到 osgi 运行时初始化的位置并更改其父级类加载器的连接方式。您甚至可以编写一个自定义过滤类加载器，以防止 OSGi 从 webapp 类加载器加载某些类。很多事情都是可能的，但也许你并不真的想走这条路......
I know that people are trying to mix Java EE and OSGi stacks, but I think that it's a recipe for problems. They both have their own expectations for how classloaders work and getting them to cooperate can be a problem.
If you must do this, you can make life easier for yourself by putting as much as possible of your web app in the osgi container. Alternatively, find the place where the osgi runtime is initialized and change how its parent's classloader is wired in. You can even write a custom filtering classloader that would prevent certain classes from being loaded by OSGi from webapp classloader. Many things are possible, but perhaps you don't really want to go down this path...