java - 通过实现扩展点非常大的模型来使OSGI服务模型更好。

Question

Closed. This question is opinion-based。它当前不接受答案。
                            
                        
                    
                
            
                    
                
                        
                            
                        
                    
                        
                            想改善这个问题吗？更新问题，以便 editing this post用事实和引用来回答。
                        
                        6年前关闭。
                    
                
        

这个问题针对的是对OSGI和开发路线图非常熟悉的人们。我在Eclipse / Equinox上长大，发现扩展点框架在构建可扩展软件时非常有价值，因为它能够通过构建架构来创建丰富的xml元数据，从而允许扩展点从Java代码中消耗掉，并且具有设计时xml验证的plugin.xml。结合使用PDE Eclipse工具定义和使用扩展点是Equinox我最喜欢的功能之一。

我想我几乎可以想到的每个上下文都使用了扩展点，从使用ECore包扩展了一个Equinox服务器端模式以将其映射到一个休眠模式，再到对web.xml扩展点进行建模，从而可以进行模块化Web应用程序开发，每个插件都可以对基于扩展名生成的单个web.xml文件做出贡献。我很喜欢以与单个扩展点类似的方式移植JSF配置文件，从而允许插件贡献托管的bean，并且在模块化Web应用程序开发的世界中，我认为扩展点是解决将丑陋的战争脱钩的绝佳解决方案。除了其他框架，如果您查看Eclipse UI，很难想象没有扩展点的生活，但是我最近在开发中遇到了十字路口，因为越来越多的利益相关者正在推动构建对任何实现都透明的OSGI应用程序像Equinox或Felix迫使我退回OSGI声明式服务作为我扩展性的主要策略

我最大的困扰是缺少一个可选的基于xml的丰富元数据层，该层用于创建诸如“服务点”之类的东西（由于缺少更好的词语），该服务点使用xml模式定义服务接口中定义的方法调用的xml表示形式。允许诸如“ service-extensions”之类的内容在xml中而不是在代码中使用OSGI服务，从而使您的开发更加灵活且易于维护。

我不知道这是否是向OSGI Services提供更高级别的元数据层的最佳方法，但这是一个很好的例子，因为它显示出使OSGI Service合同比具有xml范式的Java接口更智能的好处不只是服务绑定。像上面这样，所有用于注入服务或获取服务引用的样板代码，然后调用Java代码中的方法以完成诸如在HttpService上注册http上下文之类的简单操作，都可以在xml中完成。更进一步，即使在富客户端应用程序（例如今天的eclipse中的扩展点）或Web应用程序框架中使用纯OSGI服务构建复杂的可扩展UI框架（如果不是那么容易），也可以在其中使用一个服务点来实现。在同一框架中为具有唯一ID，URL映射和控制器的可扩展Web应用程序定义标准容器，其他服务点允许其他捆绑软件通过相对索引顺序和链接将诸如菜单选项卡之类的内容添加到主菜单中引用包中的jsp页面。 Web.xml可能会成为http服务中的服务点，从而允许捆绑包通过web.xml“服务点”的“服务扩展名”来贡献servlet映射或过滤器，这些都以xml表示，而无需引用代码中的服务并调用正确的方法。

我并不是在建议将扩展点框架移植到OSGI中，而是要遵循同样的精神，即为声明性OSGI服务使用基于xml的元数据层，从而允许服务将其服务接口中包含的方法调用公开为“服务点”。它定义为其他声明式服务或捆绑包可以通过“服务扩展”使用的xml模式。我喜欢eclipse扩展点的原因在于添加扩展很容易，您会根据捆绑包类路径获得可用扩展点的漂亮对话框，并使用PDE工具根据目标扩展的架构动态呈现扩展UI点。通过这个xml元数据层，捆绑开发人员可以将OSGI服务方法公开为“服务点”，我们可以对OSGI服务采用相同的模式，例如MANIFEST编辑器可以具有一个名为“服务扩展”的标签，当我单击“添加”会显示一个基于我可以使用的包类路径的所有可用服务点的对话框，就像PDE工具UI来创建新的“服务扩展”一样，它将围绕与“服务”关联的架构进行构建-点。”在激活我的捆绑软件期间将其转换为服务点定义的方法调用。

这就是我想使用OSGI服务的方式！我们可以在Eclipse中看到的所有简洁的UI框架，例如UI贡献或项目性质构建器，资源侦听器，您命名的编辑器贡献，可以使用OSGI Services和用于包装服务方法调用的丰富xml元数据层以类似的方式进行构建和扩展。分为“服务点”和实际调用为“服务扩展”。因此，我急切的要求是向我展示一些可以在OSGI中提供此功能的东西！如果您一无所知，那么您对采用eclipse扩展点的重要之处并在OSGI Declarative Service模型中构建类似内容的方法持赞成或反对态度，这使我们可以在普通OSGI中更轻松，更好地扩展！ -邓肯·克雷布斯

最佳答案

您基本上在争论的是扩展器模式。您说对了，并非所有事物都可以最好地表示为实现服务接口的Java对象。最好以捆绑形式将某些贡献作为静态或声明性资源提供。

Eclipse Extension Registry本质上只是更通用的扩展程序模式的一个实例。 DS和蓝图也是示例。您可以使用可移植的OSGi API（例如BundleTracker）轻松地自己实现扩展程序模式。还要确保充分利用Provide-和Require-Capability标头，以确保扩展程序实际上已被解析程序拾取并安装。

一句关于Eclipse扩展的警告……虽然有很多值得一看的地方，但是它们却使生命周期全错了。扩展注册表将使用处于RESOLVED状态的捆绑软件，但这意味着您无法控制使用哪些捆绑软件和不使用哪些捆绑软件。大多数扩展程序应仅使用STARTING或ACTIVE捆绑包，因为实际上可以控制激活状态。

更新

顺便说一下，Eclipse扩展注册表是通过几个捆绑软件实现的，据我所知，它们可以在任何标准OSGi框架（即不仅是Equinox）上工作。因此，它们之间没有任何“非OSGi”……它们只是OSGi之上的另一层。如果您真的喜欢它们，请继续使用它们！我认为，OSGi社区中大多数人不使用它们的原因是，他们真的不值得打扰。一旦习惯了使用服务和扩展器的正确方法，您可能会发现Eclipse主义的吸引力降低了。

关于java - 通过实现扩展点非常大的模型来使OSGI服务模型更好。，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19136302/

上一篇：java - 为什么会出现这样的输出呢？

下一篇：java - 以下代码段的时间复杂度是多少？

相关文章：

eclipse - 检查 $M2_HOME 环境变量和 mvn 脚本匹配

java - osgi 的好 orm

java - Aries managed-service-factory 是否也管理属性？

java - 如何调试外部 OSGI 包？

java - 提交请求时控件始终选择 GET 方法而不是 POST

java - android 将十六进制转换为字符

java - maven 版本 :prepare for Spring Boot 2. 3.1.RELEASE 的问题

java - 如何创建自定义注释并使用 APT 对其进行处理？

android - 子 Activity 完成后无法调用 onactivityresult 函数

java - 在另一个项目 Eclipse 中引用项目的输出 JAR

Answer 1

您基本上在争论的是扩展器模式。您说对了，并非所有事物都可以最好地表示为实现服务接口的Java对象。最好以捆绑形式将某些贡献作为静态或声明性资源提供。

Eclipse Extension Registry本质上只是更通用的扩展程序模式的一个实例。 DS和蓝图也是示例。您可以使用可移植的OSGi API（例如BundleTracker）轻松地自己实现扩展程序模式。还要确保充分利用Provide-和Require-Capability标头，以确保扩展程序实际上已被解析程序拾取并安装。

一句关于Eclipse扩展的警告……虽然有很多值得一看的地方，但是它们却使生命周期全错了。扩展注册表将使用处于RESOLVED状态的捆绑软件，但这意味着您无法控制使用哪些捆绑软件和不使用哪些捆绑软件。大多数扩展程序应仅使用STARTING或ACTIVE捆绑包，因为实际上可以控制激活状态。

更新

顺便说一下，Eclipse扩展注册表是通过几个捆绑软件实现的，据我所知，它们可以在任何标准OSGi框架（即不仅是Equinox）上工作。因此，它们之间没有任何“非OSGi”……它们只是OSGi之上的另一层。如果您真的喜欢它们，请继续使用它们！我认为，OSGi社区中大多数人不使用它们的原因是，他们真的不值得打扰。一旦习惯了使用服务和扩展器的正确方法，您可能会发现Eclipse主义的吸引力降低了。