OSGi - 这项技术有多成熟？
我有一个要求，我需要共享一些网络资源（jsp、html、js、images、< code>css 等）跨不同的基于 Spring 的 Struts 2 应用程序。似乎可以使用 OSGi 来实现这一点？
- 有人可以指导如何使用 OSGi 实现这一目标吗？
- 其次，我想知道 OSGi 是否足够成熟，可以在生产应用程序中使用？
提前致谢！
编辑： 我浏览了这篇帖子，似乎人们能够跨 Web 应用程序共享 Web 包。唯一的区别是他们使用 Spring MVC 来实现。我想知道Struts2应用程序是否也可以实现这一点？
编辑2：我基本上不太清楚以下内容：
- “shareable-bundle”（包含要共享的网络资源）是否会打包为.war。如果是，那么最终的 Web 上下文将从哪里形成，因为该捆绑包将再次与主“Web”应用程序共享？我期望最终的 Web 上下文是通过“可共享包”和“主”Web 应用程序的合并而形成的。它会自动发生吗？有什么想法吗？
I have a requirement where I need to share some web resources (jsp, html, js, images, css etc.) across different Spring based Struts 2 applications. And seems like OSGi can be used to achieve this?
- Can some one give some pointers on how to achieve this with
OSGi? - And secondly I want to know is
OSGimature enough to be used in production applications?
Thanks in advance!
EDIT:
I went through this post and seems like people are able to share a web bundle across web applications. The only difference is that they did it with Spring MVC. I want to know whether this can be achieved with Struts2 applications also?
EDIT 2: I am basically little unclear about the following:
- Will the 'shareable-bundle' (containing the web resources to be shared) be a .war packaged. If yes, then from where will the final web context be formed since this bundle is again to be shared with the main 'web' application? I am expecting the final web context to be formed out of the merging of the 'shareable-bundle' and the 'main' web application. Will it happen automatically? Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
虽然 OSGI 可能是一个解决方案，但它可能有点矫枉过正（并且，正如 Bozho 指出的那样，您需要一个支持 OSGI 的容器）。也许看看如何在 Maven 中跨项目共享资源 对于其他选项：
编辑：回答OP的评论。 是，其想法是创建可共享 Web 资源的程序集，并使用 maven-dependency-plugin 在“资源消费者”项目中拉取和解压该程序集。所有这些都在上面提到的博客文章中进行了解释和详细说明。如果其中有任何不清楚的地方，请告诉我。
While OSGI might be a solution, it might be a bit overkill (and, as Bozho pointed out, you'll need an OSGI capable container). Maybe have a look at How to share resources across projects in Maven for other options:
EDIT: To answer a comment from the OP. Yes, the idea it to create an assembly of the shareable web resources and to use the maven-dependency-plugin to pull and unpack the assembly in the "resource-consumer" projects. All this is explained and detailed in the blog post mentioned above. Let me know if anything is unclear in it.
OSGi 用于 Eclipse、GlassFish、ServiceMix（以及其他），这些都是成熟的软件产品。然而，它们本质上非常具体，我个人的观点是，OSGi 不太适合常见类型的项目。据我所知（如果有这方面的新闻，有人纠正我），如果你想将 OSGi 与 Web 应用程序一起使用，你将需要一个 OSGi 捆绑的 servlet 容器。此外，将资源（html、js、图像）放入 OSGi 包中可能会很麻烦。
OSGi is used in Eclipse, GlassFish, ServiceMix (and others, too), which are mature software products. However, they are very specific in nature, and my personal opinion is, that OSGi is not quite suitable for the common type projects. As far as I know (someone correct me, if there is news in this area), if you want to use OSGi with web applications, you will need an OSGi bundled servlet container. Also, putting resources (html, js, images) in OSGi bundles can be troublesome.
OSGi 是一项相当成熟的技术 - 这就是所有 Eclipse 插件的结构。然而，该技术尚未在 Web 应用程序领域获得关注，因为支持它的 Servlet 容器非常少。
如果您想阅读它，您应该查看 Craig Wells 的 Modular Java ，因为它提供了与 Spring 框架相关的 OSGi 的相当好的背景。
关于共享资源，您可能需要查看 EAR 包。我已经成功地使用它来部署具有一组通用资源的多个 WAR 文件（例如，Dojo 的压缩版本）。
例如，EAR 可以如下所示：
您可能还想阅读线程 .war 与 .ear文件来自之前的 stackoverflow 帖子。
OSGi is a fairly mature technology - this is how all Eclipse plugins are structured. However, the technology has yet to gain traction in the web app space because there are very few servlet containers that support it.
If you want to read up on it, you should check out Modular Java by Craig Wells, as it gives a fairly good background on OSGi in relation to the Spring Framework.
With regard to sharing resources, you may want to look into an EAR package. I have successfully used this to deploy multiple WAR files with a common set of resources (for example, a compressed version of Dojo).
For example, an EAR can look like:
You may also want to read up on the thread .war vs .ear file from a previous stackoverflow post.
我对 Struts（或 Spring MVC，就此而言）不太熟悉，但您可以查看 SpringSource dm服务器。它基于 Equinox、Eclipse 使用的 OSGi 容器和捆绑的 Apache Tomcat（以及 Spring 框架内容）。
使用 SpringSource 服务器，每个 war 文件都或多或少以传统方式部署，但可以通过正常的 OSGi 机制访问资源（类、服务等）。这些机制基于 OSGi 包的类加载器，这对于共享 jsps、html、css 等文件资源可能会出现问题。如果您有类似于 DefaultServlet 的东西，它可以从类加载器而不是文件系统中呈现内容，那么它可能会起作用。 （或者，哎呀，我可能会让事情变得比我需要的更复杂。）
另一方面，您可以将所有内容部署为独立的 Web 应用程序，并在客户端将它们缝合在一起。
模块化 Web 应用程序问题的第一个答案看起来非常有趣，尽管并不直接适用于 SpringSource 服务器，因为它不提供 OSGi HttpService。我相信最近的 OSGi 4.2 企业规范工作也正在朝着 SpringSource 服务器的部署战争文件作为 OSGi-bundles 方法发展。
在回答您的编辑2问题时，如果我理解正确的话，答案将使用 HttpService 动态构建，该接口提供了
在 URL 下注册 servlet 和
注册的 方法URL下的资源（文件等）。
由于这些操作是动态处理的，因此不需要任何显式合并 Web 上下文位的内容。
I'm not overly familiar with Struts (or Spring MVC, for that matter), but you might look at the SpringSource dm Server. It is based on Equinox, the OSGi container used by Eclipse, and a bundlized Apache Tomcat (as well as the Spring framework stuff).
With the SpringSource server, each war file is deployed more or less traditionally, but can access resources (classes, services, etc.) via the normal OSGi mechanisms. Those mechanisms are based around the OSGi bundle's classloaders, which might be problematic for sharing file resources like jsps, html, css, and so on. It might work if you had something similar to the DefaultServlet that rendered things from the classloader rather than the file system. (Or, heck, I might be making this more complicated than I need to.)
On the other hand, you could deploy everything as independent web applications and stitch it all together at the client end.
The first answer to the modular web apps question looks really interesting, although not directly applicable to the SpringSource server, since it does not provide the OSGi HttpService. I believe the recent OSGi 4.2 enterprise spec work is heading towards the SpringSource server's deploy-war-files-as-OSGi-bundles approach, as well.
In answer to your EDIT 2 question, if I understand it correctly, the "web context" in that answer would be built dynamically using the HttpService, which is an interface that supplies methods to
register servlets under URLs, and
register resources (files, etc.) under URLs.
Since those operations are handled dynamically, there wouldn't need to be anything explicitly merging web context bits.