我想从数据库或其他来源加载我的 OSGI jar 文件
我需要提供自定义类加载器吗？大声思考这似乎不是正确的方法，因为在类加载器内部不知道所需的版本。
Do i need to supply a custom ClassLoader ? Thinking out loud this does not appear to be the right approach because inside the classloader one does not know the required version.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
鉴于加载机制本质上是通过 URL 来工作的，我建议
尝试自定义 URL 处理程序。从逻辑上讲，您需要在使用此处理程序加载任何包之前加载并激活它，否则我认为它应该可以工作。
请参阅“URL 处理程序服务规范”，R4 OSGi 核心规范。
Glassfish 使用这种方法来安装 web 应用程序包< /a> 顺便说一句。
Given that the loading mechanism essentially works with an URL, I would suggest to
try a custom URL handler. Logically you will need to load and activate it before loading any bundles using this handler, otherwise I think it should work.
See the "URL Handlers Service Specification", R4 OSGi Core Specification.
Glassfish is using this approach to install webapp bundles btw.
一个简单的解决方案是创建您自己的引导程序包，该包将从数据库（或其他位置）配置所有其他包。 OSGi 允许您从任意
InputStream安装捆绑包，因此将其插入您想要的任何源（例如 JDBC）应该相当容易。请参阅
BundleContext.installBundle()方法了解更多详细信息。您不应该寻找“回调”，框架会通过该“回调”通知您“何时需要加载所需的依赖项”，因为自动依赖项管理（ala Maven）不是核心 OSGi 功能的一部分（尽管可以通过使用诸如 OBR 之类的服务）。
A simple solution is to create your own bootstrap bundle that will provision all other bundles from a database (or other location). OSGi allows you to install bundles from an arbitrary
InputStreamso it should be reasonably easy to plug this into whatever source you want (e.g. JDBC).See
BundleContext.installBundle()method for more details.You should not be looking for a "callback" through which the framework would notify you "when it needs to load a required dependency" since automatic dependency management (ala Maven) is not part of the core OSGi functionality (although can be achieved by using services like OBR).
查看 PAX URL 项目： http://wiki.ops4j.org/display/paxurl /Documentation
这演示了加载 OSGi 包与其存储方式的关注点分离。从理论上讲，我没有看到使用数据库作为捆绑存储的任何主要障碍，尽管我也没有看到任何明显的优势。
对于捆绑版本的观点，您需要某种机制来识别要加载的捆绑（和版本）。您可以将捆绑包与版本信息一起存储在数据库中，否则如何存储同一捆绑包的不同版本？
Have a look at the PAX URL project: http://wiki.ops4j.org/display/paxurl/Documentation
That demonstrates the separation of concerns of loading an OSGi bundle from how it is stored. In theory, I don't see any major impediment to using a database as the bundle store, though I also don't see any obvious advantages.
To your point on the bundle versions, you need some mechanism to identify which bundles (and versions) to load. You would store the bundles in the database with version information, otherwise how would you store different versions of the same bundle?
您始终可以将它们从数据库（或其他）下载到某个本地位置，然后将它们动态安装到 OSGi 框架中。您需要提供给框架的只是包的文件系统路径。当然，您必须自己编写所有粘合代码。另一方面，如果您使用 Eclipse P2，由于自动配置，您可能会拥有更多的灵活性。
You could always download them from database (or whatever) into some local location and then install them dynamically into the OSGi Framework. All you need to give to the framework is the filesystem path of the bundle. Of course, you will have to write all the glue code for this yourself. On the other hand, if you are using Eclipse P2, you might have some more flexibility thanks to the automated provisioning.