在OSGI中，我们可以在运行时更新，激活，停用捆绑软件。
但是我不知道怎么可能，因为其他人可能会使用该捆绑软件的功能。为什么这种情况不会使应用程序崩溃？
通常，在JVM中，无论何时运行任何应用程序，它都会加载源类文件和所需的Java API类文件并产生结果。
您能解释一下OSGI的基本架构是什么，以便它允许上述情况发生。
要了解这一点，您需要查看OSGi格局的两个部分：服务和（Java）类/接口。
与服务相关的激活，停用和更新由客户端（用户）与服务提供者之间的合同处理。客户端必须跟踪对可用服务的更改，并在得知要删除该服务后立即释放对服务的使用。此外，一旦更好的服务可用，它就可以跟踪其他服务的可用性以更新其参考。请注意，OSGi环境是一种协作环境：非一个环境会强制使用包实际释放对服务的引用。因此，错误的行为可能导致意外的结果。
这样：对于服务，服务的用户负责处理服务可用性的动态。
与Java类/接口相关，意味着类加载，处理由框架本身完成。卸载为其他捆绑包提供类的捆绑包（通过其Export-Package清单条目宣布）时，捆绑包提供的类对于已在使用它们的捆绑包仍然可用。仅通过隐式告知框架更新捆绑包之间的类的连接（通过org.osgi.service.packageadmin.PackageAdmin通常通过某种框架控制台提供的对服务的“刷新”操作），才能对捆绑包导入的类进行更改。在那种情况下，可以通过框架停用使用包，将其重新连接到由不同包提供的其他类，然后再次激活。
这样：对于类加载，除非明确要求这样做，否则框架不会更改初始接线。对于这些包，必须知道它们可以随时启动，加载，停止和卸载以处理变化的上下文。
也许有些情况使这一点更加清楚：假设Log捆绑包LogInterface中有一个接口定义。此接口提供一种方法：logMessage(String message)。在此定义旁边，有一个捆绑包LogProvider，提供了接口的实现，而捆绑包则利用了接口LogUser的功能。这三个捆绑软件作为捆绑软件和软件包版本在OSGi框架中安装和启动1.0.0。捆绑包LogProvider在服务注册表中注册日志服务对象，捆绑包LogUser检索该服务对象并对其进行调用以进行日志记录。
方案1：假设LogProvider软件包已更新，而没有更改接口定义，例如，不仅记录到控制台，而且记录到文件。在这种情况下，必须停止旧的LogProvider捆绑软件（版本1.0.0），并且必须将新的LogProvider捆绑软件（1.1.0）安装到框架中并启动。旧的LogProvider捆绑软件一旦停止，日志服务就会消失，并通知LogUser（必须释放服务对象）。启动新的LogProvider捆绑包后，LogUser捆绑包可以查找并使用LogProvider捆绑包1.1.0提供的新实现。
方案2：假定将新方法添加到接口定义中，以允许传递严重性代码。这意味着该logMessage(String message)方法旁边的Log接口将获得一个新方法logMessage(int severity, String message)。由于接口更改，因此将卸载捆绑LogInterface版本1.0.0，并安装并启动捆绑LogInterface版本1.1.0。当然，LogProvider捆绑包也必须更改以提供新方法的实现，因此必须安装并启动LogProvider版本1.3.0。
在这种情况下，卸载LogProvider 1.2.0并启动LogProvider版本1.3.0不会导致LogUser能够检索新提供的服务。这是因为LogProvider 1.3.0从LogInterface捆绑软件1.1.0中加载了Log接口的定义，并从LogInterface捆绑软件1.0.0中加载了LogUser。要将LogUser更新到新的接口版本，必须对LogUser捆绑软件进行捆绑刷新。在实践中，执行此“刷新”意味着LogUser捆绑包将停止，重新连接到新的LogInterface版本1.1.0捆绑包并重新启动。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句