在Java EE 6容器中使用Spring3.x应用程序的可行性-有时？
头痛的时间到了！
我们有一个由软件组成的产品，其中既有服务器又有许多客户端。我们希望用Java实现来取代它，以减少内部代码维护，并在一组更现代的技术上移动。
服务器上的服务是非常面向SOA的，队列中有许多消息，在我们看来，MDB非常适合替换现有的PHP脚本。客户端上的服务为服务器生成消息以发送和处理更新，并定期与服务器同步。服务器是真正的野兽，客户端通常是客户提供的Windows XP台式机。现在，您有了一点背景知识。
我们喜欢Java EE 6的想法，我们希望能够构建一个服务器集群。然而，我们意识到，在某些情况下，相当多的服务器功能可能会交给客户端。这意味着向客户提供大量的Java EE位。我的思想正在滑向Spring框架的领域。
那么，这听起来有多可行呢？我们是否可以编写应用程序，让我们可以在Spring容器或EE容器中运行？也许用某种方式来包装一下？
回答 1
Stack Overflow用户
发布于 2011-12-01 18:50:06
您可以编写符合Spring Framework或Java EE规范(EJB、Servlet、CDI等)的应用程序。没有“我们现在就写出来，然后再决定用什么”的说法。
您(理论上)可以使用应用服务器做出这样的决定，但不能使用您要开发的代码。
Spring不太依赖于它工作的应用服务器，因为它将应用程序的所有依赖项都带到了它的中，所以这就像是将一堆jars上传到应用服务器--即Tomcat (我猜这就是您所说的"Spring容器“)。
符合Java的解决方案依赖于应用服务器服务。您无需向应用程序容器添加任何内容--只需部署您的代码(jar、war或ear)并依赖于应用程序服务器提供的服务--即Glassfish (这就是您所说的"EE “)。
完全成熟的Java EE应用程序需要完整的Java EE配置文件，这意味着您不能在Tomcat上运行它(Tomcat基本上是一个JSP和Servlet容器-整个EE堆栈的一个小子集)。
您已经提到，您关心的是已发布应用程序的大小。请记住，这是及时的操作，以‘发货’这样的环境，现在，就我个人而言，我不认为100MB的东西是‘太大’(顺便说一句-完整版的Glassfish是65MB而不是100+ MB，它已经提供了你需要的所有服务)。
如果你关心的是CPU和内存的使用--我不敢在没有测量它或者至少找到一个可信的性能比较来源(如果存在的话)的情况下说任何话。据我所知，衡量标准纯粹是关于少数服务器的启动时间，你可能会发现它是here的。
最后-如果您更愿意使用Tomcat而不是Java EE compliant servers，同时，正如您所说的，您“喜欢JavaEE6的想法”，而不是Apache TomEE会让您感兴趣。它基本上是一个Tomcat，但带有Java服务。
https://stackoverflow.com/questions/8333410
复制相似问题
腾讯云开发者
