更多标准实践问题:
- 部署应用程序作为EAR和WAR有什么区别吗?你怎么决定?(我知道WAR只是一个web应用程序，可能有也可能没有Java EE功能，如消息传递)
- 假设我有一个Spring MVC应用程序堆栈与Hibernate (MySQL DB)，这应该作为War或EAR部署?
- 如果我不使用ejb，我们什么时候需要担心JBoss部署描述符?(只是Spring MVC)。假设我也有JMS。我们是否需要配置/更新/创建任何其他与JBoss相关的配置文件?
- 当我们打包我们的应用程序EAR/WAR时，它包含了我们应用程序所需的一切。是否有一个场景，我们需要在指定的JBoss文件夹中保留一些配置/xml文件?
- 直接从Eclipse部署或者更好地使用Ant等是常见的做法吗?优势/劣势?
显然，我是一个新手:-)。试着理解这个
1。这并不总是一个容易的决定，但对于初学者和小型项目，我想说这几乎总是一场战争。使用EAR的原因主要是将业务层与UI/Web层隔离开来。有关详细信息，请参阅这个问题:如何隔离Java EE应用程序的逻辑层
2。我可能错了，但我认为春天的人通常更喜欢战争。
3。JBoss(供应商)特定的部署描述符主要用于配置所谓的"受管理对象"和安全性。有时它们可以用于Java EE规范未涵盖的额外功能(例如为WAR设置web根目录)。受管理对象通常是数据源(到数据库的连接)和JMS目的地(队列和主题)。
在传统的Java EE方法中，必须在尽可能远离代码的地方创建它们，这通常意味着系统管理员将使用某种GUI或管理控制台在目标as中创建它们。在这种设置中，作为开发人员的您将抛出带有"未解决的依赖关系"的WAR，然后系统管理员(或"部署人员")将花费数天时间来确定这些未解决的依赖关系应该是什么。
如果开发人员和部署人员之间的通信相对良好，则WAR或EAR可能会与自述文件一起抛出，这至少可以让您了解需要哪些资源。根据组织的不同，开发团队可能无法获得关于如何解决这些"未解决的依赖关系"的任何访问或反馈。例如，可能已经创建了一个最多有5个连接的数据源，但如果某些代码确实说有10个并行查询，这可能是不够的。如果开发团队不知道确切的数据源配置，某些类型的运行时问题和性能问题可能相对难以解决。
为了缓解这些问题，一些供应商，对于某些工件，提供开发人员创建那些"未解决的依赖"，而不是使用专有的部署描述符，然后将其嵌入到WAR或EAR中。对于简单的本地JMS目的地，在大多数情况下，这就是它的结束，但对于数据源，还有更多的事情要做。也就是说，必须有一种机制来在不同阶段(如开发、测试、QA、生产等)的数据源之间进行切换。此外，在源代码中使用产品密码很少是一个好主意。
如果你有一个简单的应用程序，你想在本地试用，阶段和生产密码不是一个问题。如果你为一个(大)公司部署，它是。
在Java EE 6中，您可以使用标准描述符(web.xml、ejb-jar.xml或application.xml)定义数据源，在Java EE 7中，您可以对JMS目的地执行相同的操作。没有标准的方法来配置这些基于阶段，但有一丝希望，Java EE 8将解决这个问题(参见例如JAVAEE_SPEC-19)。供应商并不总是对这些标准化的方法感到满意，他们的主要文档几乎总是会详细地告诉您如何使用他们的专有工具和描述符来做这些事情，如果您幸运的话，还会告诉您有一种标准化的方法(然后有时会轻描淡写，或者说不建议在生产中使用它来吓唬您)。
4。主要参见第3题的回答。解决如何在阶段之间切换并将生产密码保存在WAR/EAR之外的问题的一个选择是，在AS中(在您的示例中是在JBoss中)拥有所述数据源的完整定义。在此设置中，每个应用服务器安装都绑定到特定的服务器。如果需要更新、删除或添加新的数据源，则必须与运营团队(如果有的话)进行沟通。如前所述，根据您的组织，这可能是微不足道的，也可能是几乎不可能的。
5。在开发时，您最常使用IDE进行部署。对于生产，你永远不会这样做。对于生产环境，你可以使用Ant(或Maven)构建，并通过Jenkins或Chef等工具进行部署。
- 检查这里:.war vs .ear文件
- 如果你读了前面的回应，你会猜它是"WAR"。
- 部署描述符用于管理JBoss的模块，如果没有任何冲突或不需要任何调整，则不需要任何部署描述符。如果你想向JBoss添加模块，或者配置数据源等，你可能需要使用一些JBoss文件。阅读JBoss文档获取更多信息。
- 您可以在开发阶段从eclipse进行部署，但是由于您的其他环境(鉴定、生产、测试等)应该与您的开发环境分开，并且它们不会安装任何eclipse，因此您应该习惯于从命令行管理您的服务器，并将您的war放到正确的目录中。
这是一个简短的回答，但我希望它能帮助你。