有 Java 编程相关的问题?

你可以在下面搜索框中键入要查询的问题!

java Maven tomcat插件:tomcat7:run还是tomcat7:runwar?

我正在Java web应用程序中使用tomcat7-maven-plugin。现在我可以使用命令mvn clean tomcat7:run运行我的web服务器了。最近,我注意到另一个名为tomcat7:run-war的命令来自https://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/plugin-info.html,它说:

tomcat7:run:
Runs the current project as a dynamic web application using an embedded Tomcat server.

tomcat7:run-war:
Runs the current project as a packaged web application using an embedded Tomcat server.

我知道命令tomcat7:run-war将把我的应用程序打包成一个jarwar文件,然后在嵌入式服务器中运行它。我的问题是,在什么情况下我们应该使用这个命令,tomcat7:run还不够吗?或者运行打包的应用程序会有更高的性能?我不确定。提前谢谢


共 (1) 个答案

  1. # 1 楼答案

    简短回答

    正在运行的应用程序和服务器性能相同。但是,您通常希望使用run-war,因为它提供了传递war文件的额外好处。如果您确实需要让应用程序尽可能快地在本地运行,那么您希望使用run(几乎没有这种情况)


    详细信息来了

    让我们从war文件是什么以及创建它的目的开始:

    WAR. Is the extension of a file that packages a web application directory hierarchy in ZIP format and is short for Web Archive. Java web applications are usually packaged as WAR files for deployment. [Baeldung]

    为什么java web应用程序打包为WAR

    因为WAR不仅是一个zip文件,而且(正确构建)强制执行JavaWeb应用程序规范。您可以在任何容器上部署和运行war文件。签出Wikipedia以获取更多优势

    不同的目标,不同的结果

    目标tomcat:runtomcat:run-war都在嵌入式tomcat服务器上启动应用程序tomcat:run-war包括一个额外的package目标,用于将应用程序打包到WAR文件中。该WAR文件随后将由嵌入式tomcat服务器解包,以便能够运行应用程序。因此,应用程序和服务器是相同的,但是run-war的结果是不同的,因为您得到了额外的WAR文件

    但是WAR文件有什么用处呢

    首先,它没有缺点,只是多了几秒钟的构建时间。甚至热插拔工具和功能也可以在两者之间使用WAR文件。 创建WAR文件作为该目标的一部分的主要原因是:

    • 测试
    • 多部署
    • CI管道
    • 存档

    测试构建WAR文件意味着您的构建管道将经历WAR构建的所有步骤。稍后您将部署该WAR文件(提醒:它是容器的标准),您可以测试“构建”、“解包”和“部署”步骤是否正常工作。此外,如果文件结构不正确,您可以检查该文件的结构

    多个部署。 您可以在本地构建和运行应用程序,但仍然可以将WAR文件部署到您正在运行的多个容器中。在某些行业场景中,您需要确保WAR文件在不同的容器上运行,并且可以使用该文件将其部署到任何位置

    CI管道。 您可能不仅希望本地集成应用程序,还希望将结果集成到持续集成中。也许您甚至可以自动将本地构建部署到测试服务器,但更可能的是,您在CI服务器上有一个自动流程,该流程构建WAR,在某个测试或登台系统上运行WAR,并在正确工作后转发WAR

    存档。 您可能希望保留所有以前的生成WAR文件。可能是由于上述其他原因之一,或者只是作为快速历史访问的备份。了解磁盘空间和内存使用情况如何随着应用程序的增长而变化也很有趣。归档WAR文件是一种调查方法。它们还可以部署到WAR归档服务器


    结论

    这两个目标都有其用法,但通常最好使用run-war目标,因为通过额外构建WAR文件可以获得好处

    免责声明

    由于这个话题有点过时,我可以补充如下:我只是做一个历史性的回顾。今天,每个用例的用例和需求可能会有所不同。一些流程、maven目标和插件已经过时,或者出现了更好的实践。我只是在解释这个目标制定时可能的意图