这两个appservers至少部分基于OSGI。一个（Glassfish）显然是Java EE，而另一个则不是。现在我正处于为新项目选择平台的阶段，自然选择是Glassfish v3 Prelude。这确实提出了我们应该使用S2AP的问题。
接下来的问题是：Springsource dm服务器是否提供了使用Glassfish的任何令人信服的理由？反之亦然。
答案 0 :(得分：4)
Java EE应用服务器具有分布式事务管理器。如果这一点很重要，那么可能想看看SpringSource dm是否包含这样的内容。
可以使用Spring-Framework执行XA TX，只需要您自己找到合适的XA管理器并进行集成即可。
课程XA TX已经大为耻辱。大多数人试图像瘟疫一样避免它们。例如，Amazon.com不使用它们。
我们目前在组合中使用Spring-Framework和Tomcat。我们做自己的整合。很多人都做出了类似的中间层堆栈选择。我们确实与Spring-Framework API绑定 - 就像Java EE人员与Java EE / EJB绑定一样。不要让春天的言论欺骗你。但是，它继续保持开源可供用户社区访问。
一旦进入Java EE，您就会遇到特定的Java EE供应商，因为很难在实现之间移动。据推测，EJB3可以解决这个问题，但是打赌它仍然是转换Java EE应用服务器的一项重大任务。
Frankly Spring-Framework提供了比Java EE / EJB标准更有用的API，并且它以更快的速度进行创新。
答案 1 :(得分：3)
这是一个老线程，但我认为对于遇到这个问题的人（就像我一样）分享最近的GlassFish OSGi增强功能会很有用，主要是在OSGi Enterprise RFC的区域：http://wiki.glassfish.java.net/Wiki.jsp?page=OsgiDashboard
当然还有基于@ Resource的OSGi声明服务注入，自09年12月v3以来一直存在。
答案 2 :(得分：2)
我认为SpringSource的Covalent Technologies acquisition使他们能够更好地帮助任何人使用Spring / Tomcat堆栈。与Spring dm Server一起提供的Tomcat优化可能与OSGi功能一样多或更多。
答案 3 :(得分：2)
在Glassfish中使用OSGi具有误导性。 Glassfish在内部使用OSGi作为服务器; GlassG中部署的应用程序无法使用OSGi。
使用Spring dm服务器，可以编写应用程序以使用OSGi。
OSGi对您来说是一个重要的考虑因素吗？唯一的其他真正的OSGi应用服务器是Paremus的Infiniflow。所有其他应用服务器现在都在谈论OSGi，但它是一个内部实现细节;它不适用于已部署的应用程序。
答案 4 :(得分：1)
我没有使用SpringSource dm服务器，但我相信在生产中尝试之前要等一会儿会更好。原因与它是相当新的技术有关。此外，许可方案与SpingSource（GPL）一起使用的方式也没有多大帮助，因为它实际上意味着您现在和将来都只依赖SpringSource。如果您需要对服务器的支持，那么您唯一的选择就是使用SpringSource。
答案 5 :(得分：1)
SpringSource dm Server支持模块化应用程序 - 您可以将应用程序划分为OSGi包，并共享您在应用程序之间提供的任何基础结构服务。这使您远离整体结构，例如Java EE定义的WAR。通常，这意味着您在开发期间可以获得非常快速的编辑/保存/重新部署周期。然后，OSGi允许您导出版本模块及其导出的软件包，并动态更新模块，而无需重新启动整个服务器。
SpringSource dm Server是从头开始构建的OSGi捆绑包。因此，如果不需要标准集，可以配置加载dm Server的哪些子系统。