1. 这并不总是一个容易的决定,但对于初学者和小型项目,我会说这几乎总是一场战争。使用 EAR 的原因主要是为了将业务层与 UI/Web 层隔离开来。有关更多详细信息,请参阅此问题:如何隔离 Java EE 应用程序的逻辑层
2. 我可能弄错了,但我认为 Spring 人通常更喜欢 WAR。
3. JBoss(供应商)特定的部署描述符大多需要配置所谓的“被管理对象”和安全性。有时它们可用于 Java EE 规范未涵盖的额外功能(例如,为 WAR 设置 Web 根目录)。受管对象通常是数据源(与数据库的连接)和 JMS 目标(队列和主题)。
在传统的 Java EE 方法中,这些必须尽可能远离代码创建,这通常意味着系统管理员将使用某种 GUI 或管理控制台在目标 AS 内创建它们。在此设置中,作为开发人员的您将抛出一个带有“未解决的依赖关系”的 WAR,然后系统管理员(或“部署者”)将花费数天时间弄清楚这些未解决的依赖关系应该是什么。
如果开发人员和部署人员之间的沟通相对良好,那么 WAR 或 EAR 可能会连同一个自述文件一起被扔掉,这至少可以让您了解需要哪些资源。根据组织的不同,开发团队可能无法获得有关如何解决这些“未解决的依赖项”的任何访问或反馈。例如,可能已创建最多 5 个连接的数据源,但如果某些代码确实说 10 个并行查询,这可能是不够的。如果开发团队不知道确切的数据源配置,某些类别的运行时问题和性能问题可能相对难以解决。
为了缓解这些问题,对于某些工件,一些供应商提供开发人员创建那些“未解决的依赖项”,而不是使用专有的部署描述符,然后将其嵌入到 WAR 或 EAR 中。对于简单的本地 JMS 目标,在大多数情况下,这就是它的结尾,但对于数据源,还有更多内容。也就是说,必须有一种机制可以在不同阶段(例如 Dev、Beta、QA、Production 等)的数据源之间切换。此外,在源代码中包含生产密码并不是一个好主意。
如果您想在本地试用一个简单的应用程序,则无需担心阶段和生产密码。如果您为(大型)公司部署它。
在 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 内部)拥有所述数据源的完整定义。在此设置中,每个 AS 安装都与特定服务器相关联。如果需要更新、删除或添加新数据源,您必须与您的运营团队(如果有)进行沟通。如前所述,根据您的组织,这可能是微不足道的,实际上是不可能的。
5. 开发时,您最常使用 IDE 进行部署。对于生产,你永远不会这样做。对于生产,您可以使用 Ant(或 Maven)构建并通过诸如 Jenkins 或 Chef 之类的东西进行部署。