将接缝应用程序移至OSGI [英] Move a seam application to OSGI
问题描述
我使用Seam Framework 2.3 + jBoss AS 7 + Hybernate开发了一些Web应用程序.
i' ve some web applications developed using Seam Framework 2.3 + jBoss AS 7 + Hybernate.
由于我已经研究OSGI一段时间了，所以我想知道是否可以将我的应用程序迁移到osgi世界中，以便对所有内容进行模块化.我已经阅读了很多博客以及这些有趣的讨论(如何模块化-a-jsf-facelets-spring-application-with )，但老实说，我仍然不知道在哪里我应该从头开始，因为我以前从未使用过OSGI.
Since i' ve been studying OSGI for a while, i was wondering if is possible to move my applications to the osgi world for modularizing everything; i' ve read a lot of blogs and these interesting discussions as well (how-to-modularize-an-enterprise-application-with-osgi-and-ee6 and how-to-modularize-a-jsf-facelets-spring-application-with-osgi) but honestly i still don't really know where i should start from, since i' ve never used OSGI before.
根据您的情况
- 是否有可能(而且有用)做这些事情?
- 根据您的经验，什么是一个很好的起点?
感谢帮助
推荐答案
方法
可能从玩具应用程序开始，例如尖钉，WAB(OSGi WAR)和单一服务包.
Possibly start with a toy application as a spike, a WAB (OSGi WAR) and single service bundle.
绝对采用迭代方法.据我所知，JBoss通过JBoss modules/msc支持OSGi服务和Java EE的混合，这将允许您尝试OSGi并逐步迁移.
Definitely take an iterative approach. As far as I know JBoss supports the mixing of OSGi services and Java EE stuff, via JBoss modules/msc, this will allow you to try OSGi and migrate gradually.
我认为您会发现某些事情非常简单，而另一些事情则非常困难，因此在熟悉时选择轻松的战斗.最后，您可能会坚持使用混合方法.
I think you'll find some things are incredibly easy and others very hard, so pick easy battles while you're getting familiar. In the end you may stick with a hybrid approach.
构建
您的构建工具是什么?通常与Maven或Ant类似，在这种情况下，请查看 maven-bundle-plugin 或 bnd .您需要确保每个包中都包含OSGi元数据(Bundle-SymbolicName，Import-Package，Export-Package等).如果您使用的是Maven，请参见此答案.
What's your build tool? Mostly like Maven or Ant, in which case have a look at maven-bundle-plugin or bnd respectively. You'll need to ensure the OSGi metadata is present in each of your bundles (Bundle-SymbolicName, Import-Package, Export-Package, etc). If you're using Maven see this answer.
将整体应用程序划分为模块可能很棘手，但是作为一般规则，当您迁移大小合理的模块时，应该为API和实现提供单独的捆绑包(无论如何，这都是很好的设计，但对运行时也有影响)
It can be tricky to divide a monolithic app into modules, but as a general rule when you migrate a reasonable sized module you should have separate bundles for API and implementation (which is good design anyway but has implications for the runtime too).
互操作
您可以从注入的BundleContext中使用低级框架API获取OSGi服务，访问包等，这将为您提供进入OSGi的低级编程挂钩.它应该像这样简单:
You can acquire OSGi services, access bundles etc using the low level framework APIs from an injected BundleContext, which will give you a low-level programmatic hook into OSGi. It should be as simple as:
@Resource
BundleContext context;
除非将Java EE代码打包为JBoss模块，否则我认为不求助于JNDI之类的方法来调用另一种方式(例如OSGi服务查找Java EE服务)并不容易.
Unless your Java EE code is packaged as JBoss modules I don't think it will be easy for you to call the other way (e.g. OSGi service looking up Java EE service) without resorting to something like JNDI.
您应该能够安装Web控制台并查看OSGi中注册了哪些Java EE位，并且类似地检查JNDI以查看适用于Java EE的OSGi.
You should be able to install the webconsole and see what Java EE bits are registered in OSGi, and similarly check JNDI to see what's available OSGi for Java EE.
迁移服务
虽然OSGi很有趣，但是使用原始框架API会产生大量样板代码，并且不太可能需要电源或需要耦合.您可以在OSGi之上使用许多依赖项注入框架.蓝图(类似Spring)，Peaberry(Guice)和声明式服务.
While OSGi is a lot of fun, using the raw framework API results in quite a bit of boilerplate code and it's unlikely you'll need the power or want the coupling. You can use a number of dependency injection frameworks on top of OSGi; blueprint (Spring-like), Peaberry (Guice) and Declarative Services for example.
我有偏见，但是声明式服务对OSGi µservice模型具有很强的亲和力，并且实现是轻量级的.
I'm biased but Declarative Services has a strong affinity to the OSGi µservice model and the implementations are lightweight.
CDI
我对Seam/CDI不太了解，但是 Pax CDI 可能会有所帮助(尽管JBoss可能已经对此进行了介绍).
I don't know much about Seam/CDI, but Pax CDI might help (though JBoss might already have covered this).
网络
您是否打算使用高度模块化的UI并热部署各个组件?如果不是，那么最好将UI打包为WAB. WAB是一个瘦的WAR(即，它导入而不是嵌入大多数依赖项).即使您追求的是高度模块化，动态的前端，我也肯定会在第一遍就这样做.
Are you planning to have a highly modular UI with hot deploy of the various components? If not then probably best just to package the UI as a WAB. A WAB is a skinny WAR (i.e. it imports rather than embeds most dependencies). Even if you're after a highly modular, dynamic frontend, I would definitely do this for the first pass.
JPA
一个警告-JPA实现通常在OSGi环境中不能很好地发挥作用，您可能希望查看Apache Aries或Eclipse Gemini.另一种选择可能是将JPA内容留在Java EE空间中，并作为OSGi服务访问Java EE DAO/存储库.同样，尽管您可能会遇到一些类加载问题.
A word of warning - JPA implementations typically don't play well in OSGi environments, you may want to look at Apache Aries or Eclipse Gemini. Another option might be to leave the JPA stuff in Java EE space and access Java EE DAOs/Repositories as OSGi services. Again though you may experience some classloading issues.
可能有用的示例 https://docs.jboss.org/author/display/JBOSGI/Provided + Examples
这篇关于将接缝应用程序移至OSGI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
