OSGi和...?如何控制包裹的装载/卸载/重新装载? [英] OSGi and ...? What do I use to controll loading/unloading/reloading of packages?

问题描述

我有一个大型的应用程序和库生态系统，当前已作为.jars的集合部署在各种应用程序服务器(例如JBoss AS)中，并且我正在尝试找到一套很好的工具来管理依赖关系和生命-各种包装的周期.

I have a large ecosystem of applications and libraries which are currently deployed as a collection of .jars in various application servers (e.g. JBoss AS), and I'm trying to figure out a good set of tools to manage dependencies and life-cycles of the various packages.

我认为这些软件包处于(至少)三种可能的状态之一:未加载"，待处理"和已加载"，其定义如下:

I think of the packages as being in one of (at least) three possible states: "unloaded", "pending" and "loaded", loosely defined as follows:

• 已卸载:该软件包目前不可用.
• 待定:该程序包本身可用，但不是其所有依赖项.因此，目前无法使用.
• 已加载:该程序包可用，并且已满足其所有依赖性.如果是应用程序，则可以运行-如果是库，则可以被其他程序包使用.

• Unloaded: The package is not available at the moment.
• Pending: The package itself is available, but not all its dependencies. Therefore, it cannot be used at the moment.
• Loaded: The package is available and has all its dependencies satisfied. If it's an application, it can run - if it's a library, it is ready to be used by another package.

(可能还会有更多状态，例如试图加载但由于某种原因(不满足依赖关系而导致失败)的程序包失败"，等等)

(There might also be a few more states, such as "failed" for packages that tried to load but failed for some other reason than that dependencies were not satisfied, etc...)

在程序包的生命周期中，许多原因可能导致程序包在这三个状态之间更改状态:

In the life-cycle of a package, a number of things might cause a package to change state between these three:

• 一个没有依赖性的软件包被加载，并且从 unloaded 变为 loaded .
• 一个软件包试图加载，但是并不是所有的依赖关系都得到满足；从已卸载到待处理.
• 处于 pending 状态的软件包突然满足了其所有依赖性(因为其他一些软件包进入了 loaded 状态)，并自动开始进行自身加载；从待处理到已加载的过渡.
• 软件包已卸载.所有依赖于当前已卸载软件包的已加载软件包将从 loaded 变为 pending .
• 一个软件包已更新为较新的版本.所有从属软件包都会自动重新加载，以访问更新的版本.

• A package with no dependencies is loaded, and goes from unloaded to loaded.
• A package tries to load, but not all dependencies are satisfied; it goes from unloaded to pending.
• A package in pending state suddenly has all its dependencies satisfied (because some other package went to state loaded), and automatically starts loading itself; transition from pending to loaded.
• A package is unloaded. All loaded packages which depend on the now unloaded package go from loaded to pending.
• A package is updated to a newer version. All dependent packages are automatically reloaded, to get access to the updated version.

我已经开始使用OSGi来定义依赖项-它可以在我们的构建系统中很好地运行并产生可靠的依赖项信息.但是，如果我将两个OSGi软件包A和B加载到JBoss中，其中B依赖于A，然后卸载A，似乎B会幸福地继续运行.我已经了解到可以使用一些挂钩在较低级别(框架事件)上进行控制，但是我的蜘蛛感觉有些刺痛，说一定有更好的方法可以做到这一点

I've started working on using OSGi for defining the dependencies - it rolls well with our build system and produces reliable dependency information. However, if I load the two OSGi bundles A and B into JBoss, where B depends on A, and then unload A, it seems like B happily keeps running. I've understood that there are some hooks that I could use to control this on a low level (framework events), but my spider sense is tingling, saying that there must be a better way to do this.

是否有一个不错的工具/框架/您想调用的工具在这些方面都可以给OSGi锦上添花?

Is there a nice tool/framework/whatever-you-want-to-call-it that will compliment OSGi in these aspects?

推荐答案

如果您声明模块之间的依赖关系，则将适当地管理生命周期，并且必须在停止顶级模块之前停止后代的依赖关系.

If you declare dependancy between modules, the lifecycle is properly managed and the descendant depandancies must be stopped before the top-level module is stopped.

但是，停止模块只不过是将事件发送到包激活器并从类加载器中删除引用而已.任何活动(例如线程或分布式实例)都必须手动清理.例如，您必须调用org.apache.commons.logging.LogFactory.release(ClassLoader)(如果使用公用日志记录)或删除任何注入的UI组件.

However, stopping a module does nothing more than sending events to the bundle activator and removing references from classloader. Any activities (such as thread or distributed instances) must be manually clean. For example, you must call org.apache.commons.logging.LogFactory.release(ClassLoader) (if using commons logging) or remove any injected UI-component.

这篇关于OSGi和...?如何控制包裹的装载/卸载/重新装载?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！