java – 用于发送Web应用程序的EAR与RPM？

发布时间：2020-12-14 19:15:45 所属栏目：Java 来源：网络整理

导读：将Web应用程序发布到生产环境时,您会考虑企业应用程序存档还是RPM？每个人的缺点和优点是什么？使用RPM,您可以跟踪版本控制并正确处理配置文件. 假设您的应用程序不会安装在Windows机器上,因此操作系统依赖性不是我们担心的问题. 最佳答案我使用或研究过

将Web应用程序发布到生产环境时,您会考虑企业应用程序存档还是RPM？

每个人的缺点和优点是什么？

使用RPM,您可以跟踪版本控制并正确处理配置文件.

假设您的应用程序不会安装在Windows机器上,因此操作系统依赖性不是我们担心的问题.

最佳答案

我使用或研究过的大多数Java Web应用程序通常都是作为Enterprise或Web存档发布的.除了非常具体的场景外,RPM的情况非常薄弱.

有几点支持EAR / WAR文件：

>安装通常很容易,即使它涉及将EAR / WAR文件复制/上载到指定目录的一些手动过程.但是,您需要在此处了解目标受众.如果您希望Linux系统管理员(对Java应用程序服务器知之甚少或根本不了解)正在执行应用程序的安装和维护,那么您可能正确选择RPM.然而,对于企业而言,这是一种罕见的情况,因为从支持的角度来看,这种情况不那么重要;在生产中遇到安装/配置问题时,您根本不希望受到第三方应用程序开发人员的支配.
> EAR / WAR文件可以以允许便携式安装的方式发布.理论上可以使用单个构建支持多个容器.这比要求每个容器发布RPM要好得多;每个RPM都必须安装特定于应用程序的容器,并将EAR / WAR文件发布到此嵌入式容器.如果您希望让您的客户选择部署到他们自己的容器上,那么仅RPM部署模型将要求他们从RPM中提取EAR / WAR文件,然后自行执行部署.
> RPM不能用于以标准方式部署应用程序,跨WebLogic,WebSphere等商业容器.除非您希望客户使用涉及目录布局,群集模式等的标准安装模型,否则无法完成.内部创建以针对单个客户创建,可能没有此问题,因为可以建立有关如何安装和配置容器的内部标准.

从上述陈述中推断,EAR / WAR文件应始终可用于满足客户需求,并且增加了为无障碍安装提供RPM的可能性.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!