3

かなり遅い VPN 接続を介して巨大な (40 ～ 50 MB) EAR ファイルをサーバーにデプロイする方法を見つけようとしています。EAR には、Glassfish で作成された EJB および WAR プロジェクトが含まれており、ファイル サイズの 90% は、使用されている外部の依存ライブラリからのものです。

  1. Netbeans から実稼働システムへのエレガントな展開のための戦略を思いついた人はいますか? (ネットワーク経由の) 展開は本当に必要なものに対してのみ行われます (つまり、EAR 全体ではなく 1 つの WAR、または 1 つのライブラリのみ)。ライブラリサブプロジェクト全体)。

  2. 最初のポイントに関連して、プロジェクトが開発マシンでコンパイルされるように、Netbeans のプロジェクトから外部依存関係ライブラリを分離する方法ですが、EAR/WAR/EJB が作成されたときにすべての依存関係 JAR が含まれていないため、巨大になっています。 .

カスタム ant スクリプトを作成する必要があるのではないでしょうか? Mavenを使い始めますか？

みなさん親切な回答ありがとうございます

ボゾ

4

3 に答える 3

4

依存関係を EAR から共有ディレクトリに移動するのが悪い考えである理由は次のとおりです。すべての依存関係を EAR 内に保持することで、アプリケーション サーバーはその EAR を完全にアンデプロイ/再デプロイし、その EAR 内で使用されていたスペースを再利用できます。 JVM ヒープ (Sun JVM の場合は permgen)。一部の依存関係を共有ライブラリに移動すると、それらの依存関係が EAR 内で定義されたオブジェクトへのハード参照を維持するというリスクが生じます。これは、EAR クラスを削除できないことを意味し、最終的に permgen スペースを使い果たした後、アプリ サーバーがクラッシュします。

「VPN」が Windows SMB を意味するという仮定に基づく SSH の私の提案は、ファイルをコピーするときに多くのやり取りが行われます。SSH (正確には SCP または RSYNC) を使用すると、接続の全帯域幅を使用できます。

それでも遅すぎる場合は、インフラストラクチャの変更を検討する必要があります。私にとって VPN は企業ネットワークを意味するので、展開マシンと同じネットワーク セグメント上にビルド マシンをセットアップすることができるかもしれません。とにかく、プロセスの観点からは、これははるかに優れたアイデアです。開発者ワークステーションからビルドをデプロイするべきではありません。代わりに、ソースをクリーンな環境にチェックアウトし、ビルドを行い、テストを実行してからデプロイする必要があります。

別の方法は、特定のアプリ サーブが「爆発耳」をサポートしているかどうかを確認することです。サポートしている場合は、変更された JAR をアップロードするだけです。

于 2009-10-15T12:10:43.813 に答える
1

合理的なアプローチは、EARをローカルで構築し、rsyncを使用してファイルをミラーリングしてから、再デプロイをトリガーすることです。基になるjarが変更されない場合、EARファイルのほとんどの部分は変更されないため、rsyncアルゴリズムから大きなメリットが得られます。

于 2010-03-18T09:39:11.687 に答える
0

ライブラリ jar を /glassfish installation dir/glassfish/domains/domain1/lib にコピーして、それらを ear ファイルにパッケージ化しないのはなぜですか?

于 2012-02-08T19:27:41.187 に答える