播放框架和 OSGI答案

【问题标题】：Play framework and OSGI播放框架和 OSGI
【发布时间】：2011-09-30 02:01:17
【问题描述】：

是否可以将播放框架与 OSGI 集成以创建可插入组件？有人试过吗？

【问题讨论】：

请说明放负的原因。谢谢
我同意它不应该是负面的，我只是撞到了你。我还没有在 OSGI 和 Play 上看到任何东西。
我曾经尝试阅读过 OSGi 标准，并认为它是由提出 J2EE 的同一批白痴编写的。但是，我可能很愚蠢:)。所以我的问题 - 你为什么想要它？我有兴趣在这里看到好处（并被证明是错误的:-)）
我没有任何玩游戏的经验！框架，但 OSGi 框架非常敏捷，您可以在单个 VM 中启动任意多个，它们在 WAR 中的 JEE 容器中运行，或者它们作为 JEE 容器运行在顶部。因此，将 OSGi 框架集成到任何基于 JVM 的代码中应该不会很困难。
@cdegroot 我认为我们可以两全其美，OSGI 的模块化加上 Play 框架的敏捷开发......也许像 Pax Wicket ohloh.net/p/6298

【解决方案1】：

如果您的意思是“使用 OSGi 创建 Play 模块”，那么不，不支持

如果您的意思是“将 Play 部署为 OSGi 模块”，那么不，它不受支持

公平地说，没有理由推动它的支持。您可以在 OSGi 上阅读 Spring 创始人的 these thoughts 作为示例。 OSGi 会给 Play 增加额外的复杂性，而 Play 的主要目标是成为一个快速的开发平台，使用简单，去除一些 Java 约定（如 Sessions）。这会破坏目的。

【讨论】：

另一方面，像 BIRT 这样的报告引擎是 OSGI 捆绑包。我希望这可以整合。但我不确定这是否真的触及问题。
我认为如果你仔细阅读 OSGi 不会增加额外的复杂性，问题是我们所知道的 Spring (IoC) 需要模块的实现细节。问题是，如果强大的模块化有优势，我认为确实如此，但它要求你的代码是模块化的......
@pere-villega 谢谢。非常有用的链接。我会尝试类似的方法来看看这个框架的行为。
这里是不必要的 OSGi FUD（恐惧、不确定性和怀疑）。 OSGi 使事情复杂化是完全不正确的。
@derekm 这是 2011 年回答的问题，6 年后情况可能发生了变化；）

【解决方案2】：

如果我们正在讨论 Play 2，那么绝对值得承认的是，Play 现在的一个重要且不可或缺的部分是 Akka，它可以被视为 OSGi 的替代品。从哲学上讲，我认为 Akka 与 Play 和 Scala 的核心原则（一种功能性、无状态、NIO 方法）有很多共同之处，而 OSGi 更符合 Java EE/Spring 阵营。

这并不是说 Akka 和 OSGi 是完全互斥的：Akka's documentation 建议您可以将 Akka 部署为 OSGi 包并创建一些突变应用程序，让 Akka 演员通过 OSGi 包启动。

但要回答这个问题，不，Play 不支持 OSGi，但它非常支持 Akka。

【讨论】：

OSGi 的 Akka 替代品？你能详细说明一下吗？
OSGi 的 Akka 替代品？你能详细说明一下吗？ Akka 是关于使用 Actor 模型 (en.wikipedia.org/wiki/Actor_model) 解决并发问题。 OSGI 是关于提供和使用它们的服务/接口的松散耦合模块，关于在运行时将它们插入和拔出——只是松散耦合。您能告诉我们这些概念如何重叠甚至可以替代吗？
道歉 - 我并不是说 Akka 和 OSGi 是同一事物的不同实现，只是其中一个可以使用 Akka 实现面向服务的方法。我没有个人经验，只有我在回答时正在做的一些研究。请参阅blog.kreuzverweis.com/uncategorized/… 了解其他人对此的看法。
我在 OSGi 中有 Akka github.com/PhilAndrew/JumpMicro