无法从货物部署到Tomcat7

时间:2011-10-06 13:50:45

标签: tomcat7 maven-cargo

我正尝试通过https部署到Maven的Cargo远程Tomcat7。

我已经设置了manager-script角色,并且我已经成功地远程取消部署应用程序。

我看起来像这样:

<plugin>
    <groupId>org.codehaus.cargo</groupId>
    <artifactId>cargo-maven2-plugin</artifactId>
    <version>1.1.2</version>
    <configuration>
        <container>
            <containerId>tomcat7x</containerId>
            <type>remote</type>
        </container>

        <configuration>
            <type>runtime</type>
            <properties>
                <cargo.remote.uri>https://xxx/manager/text</cargo.remote.uri>
                <cargo.remote.username>${tomcat.username}</cargo.remote.username>
                <cargo.remote.password>${tomcat.password}</cargo.remote.password>
            </properties>
        </configuration>

        <deployer>
            <type>remote</type>
            <deployables>
                <deployable>
                    <groupId>mycomp</groupId>
                    <artifactId>myartifact</artifactId>
                    <type>war</type>
                    <properties>
                        <context>/</context>
                    </properties>
                </deployable>
            </deployables>
        </deployer>

    </configuration>
</plugin>

嗯,我知道凭据和一切都设置正确,我使用了新的/文本界面,我已经能够取消部署现有的应用程序。但是在尝试运行deploy时:

mvn cargo:deployer-deploy -e

我的根本原因是错误的:

Caused by: java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2809)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2792)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.pipe(TomcatManager.java:605)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:501)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deployImpl(TomcatManager.java:569)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:273)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:256)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:240)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:101)
... 25 more

我立即得到它,所以不能超时。

文件可以变大吗?这是一场60 MB的战争。我确保我的nginx允许更大:

client_max_body_size 200M;

我还在管理器webapps web.xml中的文本管理器中添加了multipart配置,如下所示:

的servlet&GT;     经理     org.apache.catalina.manager.ManagerServlet            调试       2     

<multipart-config>
  <max-file-size>209715200</max-file-size>
  <max-request-size>209715200</max-request-size>
  <file-size-threshold>0</file-size-threshold>
</multipart-config>

http://nexnet.wordpress.com/2011/04/27/large-war-file-cannot-be-deployed-in-tomcat-7/

我在很多方面都喜欢Maven,但错误报告非常糟糕。任何帮助高度赞赏。

4 个答案:

答案 0 :(得分:2)

最近,当我尝试cargo:deploy一件神器时,我被这个错误所困扰。通常我们在部署之前停止,清理并启动 webapps 目录,但这次我注意到没有删除一个工件。

切换到cargo:redeploy后,错误已解决。

答案 1 :(得分:1)

使用ant deploy任务部署到tomcat 8服务器时遇到了同样的错误消息。我的问题是我的服务器空间不足。检查tomcat的经理日志是我的理由:

10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/abc_beta'
10-Jul-2014 10:15:38.065 INFO [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /usr/share/apache-tomcat-8.0.9/webapps/abc_beta.war
10-Jul-2014 10:15:57.962 SEVERE [http-nio-8080-exec-2] org.apache.catalina.core.ApplicationContext.log Manager: managerServlet.check[/abc_beta]
    java.io.IOException: No space left on device
    ... stacktrace ...

答案 2 :(得分:0)

我不记得我是否或如何解决这个问题,但由于rascio有同样的问题,我会发表一个想法。也许这是ssl所需的马车延伸:

    <extensions>
        <extension>
            <groupId>org.apache.maven.wagon</groupId>
            <artifactId>wagon-ssh</artifactId>
            <version>2.2</version>
        </extension>
    </extensions>

狂野的猜测。我认为你在Maven 3.0之前不需要它。

答案 3 :(得分:0)

这个例外的另一个原因是我们在星期一突然偶然发现,当我们的 Jenkins 实例上的部署作业使用 cargo plugin 插件停止工作时。不是全部,而是一些。主要区别在于Nexus存储库的作业中的自定义 settings.xml ,可从中下载可部署的内容。

成功部署作业的配置与https://support.sonatype.com/entries/20943003-configure-maven-to-download-from-nexus中描述的相同,失败的作业错过了repositorypluginRepository

我仍然不确定为什么行为会在某一时刻发生变化。任何tipps?