8

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>

資格情報とすべてが正しくセットアップされていることはわかっています。また、新しい /text インターフェイスを使用して、既存のアプリをアンデプロイできました。しかし、デプロイを実行しようとすると:

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

すぐに取得できるので、タイムアウトになることはありません。

ファイルが大きすぎる可能性はありますか? 60MB戦争です。私のnginxがより大きくできることを確認しました：

client_max_body_size 200M;

また、次のように、マネージャー webapps web.xml のテキスト マネージャーにマルチパート構成を追加しました。

サーブレット > マネージャー 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

4 に答える 4

3

cargo:deploy最近、アーティファクトを作成しようとしたときに、このエラーに悩まされました。通常、デプロイする前にwebappsディレクトリを停止し、クリーンアップしてから開始しますが、今回は 1 つのアーティファクトが削除されていないことに気付きました。

cargo:redeployエラーに切り替えた後、解決しました。

于 2015-01-28T07:27:40.280 に答える
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 ...
于 2014-07-10T16:40:09.957 に答える
0

これを解決したかどうか、どのように解決したかは覚えていませんが、rascioにも同じ問題があるので、アイデアを投稿します。多分それは必要なsslのワゴン拡張です：

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

しかし、ワイルドな推測。Maven3.0以前は必要なかったと思います。

于 2012-05-11T11:50:40.493 に答える
0

この例外のもう 1 つの理由は、貨物プラグイン プラグインを使用したJenkinsインスタンスのデプロイ ジョブが機能しなくなった月曜日に突然出くわしたことです。それらのすべてではありませんが、一部です。主な違いは、デプロイ可能なものをダウンロードするNexusリポジトリのジョブのカスタムsettings.xmlでした。

成功したデプロイ ジョブでは、https://support.sonatype.com/entries/20943003-configure-maven-to-download-from-nexusで説明されているように構成されていましたが、失敗したジョブには、repositoryおよびpluginRepository

ある時点で動作が変わった理由はまだわかりません。ヒントはありますか？

于 2015-02-11T15:12:53.930 に答える