問題タブ [ear]

私が質問を正しく表現したかどうかさえわかりません。グーグルを試しましたが、関連するものが見つかりません。

基本的に、ear ファイルから JDeveloper で作業プロジェクト フォルダを作成する必要があります。私が持っているのは ear ファイルだけで、コードを変更できるようにする必要があります。耳には戦争があり、戦争には多数のjarファイルがあります。ファイルのパッケージ化とデプロイの経験はありません。また、ear ファイルを取得して作業プロジェクト フォルダーを作成する方法についての経験も明らかに少ないです。

どんな助けでも大歓迎です。

私の耳のすべての Web アプリケーションに共通するいくつかのクラスを Java ee 5 アプリケーションにロードしようとしています。

クラス（jarではない）を「lib」というディレクトリに配置することでこれを実行しようとしました

b) application.xml にも指定する

であり、オプション a または b のいずれによっても成功しなかった

しかし、クラスをcommon.jarにjarしたとき、メソッドbでクラスをロードできました)

1. これらのメソッドは両方とも、クラスを jar にする必要がありますか?
2. 上記の 2 つの方法でクラスを提供することの違いは何ですか? 共通クラスのロードを指定する方法が 2 つあるように見えるのはなぜですか?

私はmaven2が初めてです。昨日まで、maven2から戦争を構築することに成功しました。私の次の目標は、いくつかのjarファイルも含むwarファイルのearファイルを構築することです。

それを手伝ってくれませんか。大変感謝しております。

よろしく Gnash-85

タイトルで述べたように、ear をビルドするときにアーティファクト (wars と ejbs) が ear 内にコピーされますが、APP-INF/lib が欠落しており、何が原因かわかりません。

これは pom.xml の一部です:

また、/contentEar フォルダーには application.xml ファイルとマニフェスト ファイルしかありません。

これについてのアイデアがあれば、私を助けてください...

Application Client モジュールを使用した EAR アプリケーションがあります。

この EAR ファイルが GlassFish v2にデプロイされ、Application Client モジュールがキャッシュに存在する場合、Application Client の起動中のクライアント マシンとサーバー間のトラフィック量は約 1 です。0.7KB。

しかし、このアプリケーションを GlassFish v3にデプロイし、アプリケーション クライアント モジュールを 2 回目または 3 回目に起動すると (キャッシュに既に存在するように)、アプリケーション クライアント起動時のクライアント マシンとサーバー間のトラフィック量は 10MB になります。

何が間違っている可能性がありますか？

更新 1

「Hello World」を出力するだけの Application Client コンポーネントを使用して単純な EAR プロジェクトを作成し、それを GlassFish v3 にデプロイしても、Application Client がキャッシュから起動されるたびに 5 ～ 6MB になります。

更新 2

問題をより深く掘り下げようとしています。GlassFish v3 のキャッシュからアプリケーションを起動すると、アプリケーション クライアントの各ライブラリ
の GlassFish v3 ログに次の例外が記録されます。

例えば：

私は、トラフィックのオーバーヘッドが関連している可能性があると仮定しています。この問題については、インターネット上にいくつかの情報があります。しかし、明らかに公式の説明や修正方法はありません。
これは、この問題に関連する興味深いスレッドであり、いくつかの光を当てる可能性があります。
ティム（よりtjquinn）が状況についてコメントした方法は次のとおりです。

「確立された接続が中止されました」というメッセージは私たちが見たものですが、あなたが言ったように、起動には影響しないようです. 私は、Java Web Start が JAR のダウンロードを開始し、キャッシュされたコピーが最新であることを発見し、転送を中止すると思いますが、確認していません。これは起こるべきではありませんが、それが Java Web Start の問題なのか、Grizzly の問題 (基本的に GlassFish のトランスポート層) なのか、GlassFish 自体の問題なのかを正確に認識させている原因を特定できていません。

UPD 3同様の問題 について、「Old Nabble」で興味深い議論があります。また、アプリケーション クライアントを起動した後、Web サービスの障害の症状が発生しました。

UPD 4 Grizzly フォーラム (UPD 3 で言及されているスレッド) の Oleksiy Stashok は、Java Web Start フォーラムに質問を投稿することを提案しました。Java Web Start フォーラムのスレッドへのリンクは次のとおりです。

struts-hibernate Java EE プロジェクトで maven2 を使用し、myEclipse で開発しています。maven ビルドの clean&install を実行すると、通常どおり myProject_ear\target フォルダーの下に myProject.ear が生成されます。ただし、この ear ファイルをそのフォルダーから ..jboss-4.2.2.GA_2\server\default\deploy フォルダーにコピーしてデプロイし、再び Eclipse に戻ってサーバーを起動する必要があります。

これは、私のプロジェクトに標準の Java EE スケルトンがないためだと思います。ただし、jboss の ..\deploy フォルダーの下に自分の耳を自動的にデプロイするように Maven に指示する方法があれば、それを聞いてうれしいです。

私はしばらくの間見回してきましたが、これについての明確な説明を見つけることができませんでした。

Rational Software Architect 7 を使用して開発された Web アプリケーションを実行するために、Websphere サーバーを使用しています。このアプリケーションは、war プロジェクトと 4 つの jar プロジェクトで構成されています。最終的な ear ファイルを作成するために、IBM がそれをデプロイするために必要な追加ファイルを含む 6 番目のプロジェクトがあります。

現在、EAR ファイルを生成するには RSA を使用する必要があります。そのためにMavenを使用したいと思います。

どうやら以前の試みで maven-ear プラグインを使用すると、破損した耳が生成されたようです。IBM が必要とする追加の xml ファイルが欠落しているように見えます。

maven was-6 プラグインを見つけましたが、ファイルを生成できず、websphere にインストールするだけです。それが何をするのかについての明確な説明を見つけることができませんでした。

誰かアドバイスはありますか？いくつかの記事へのリンク ?

どうもありがとうございました ！

現在、ant ベースのプロジェクトがあり、maven への移行を検討しています。このプロジェクトは Java ee ベースですが、各モジュールに複数の Java ee プロジェクトを含めることができるモジュール構造になっています。このような：

複数のそのようなモジュールといくつかの jar 依存関係が追加され、1 つの EAR ファイルが作成されます。+ カスタム マニフェスト ファイル

そのようです

この構造と依存関係は変更できません。これは、私たちが使用するフレームワークに由来します。

これがどれだけの作業であるかを理解するのにmavenについて十分に知りません。または、プロジェクトの構造と開発慣行がmavenの慣習から遠く離れているため、時間の価値がないかどうかを判断します。

Maven を好きなように曲げることができることは理解していますが、切り替える場合は、maven の利点が人生を難しくしないようにする必要があります。:)

もう 1 つの重要なことは、ear ファイルを分解して作成できるようにしたいということです...その側面をカスタマイズするには、どのようなオプションが必要ですか? カスタマイズされた「タスク」を使用する場合、何をあきらめることになりますか (これについての専門用語が何であるかはわかりません)

Mavenが対象の EAR アーティファクトにweblogic-application.xml配置できるようにするには、Maven 2 プロジェクトのどこに配置すればよいですか?META_INF

私のアプリケーションは EAR ファイルとしてデプロイされます。

このアプリケーションでは、従来、インストール後に構成を変更する必要がありました。

Oracle 10G OAS では、EAR がディレクトリに展開され、構成ファイルに簡単にアクセスできるため、これは簡単でした。

11G では、EAR は展開されないため、EAR の展開、変更、および再結合に関する追加のドキュメントが作成されます。

これは、おそらく J2EE を介した標準的なソリューションでは比較的一般的な問題であるに違いないと思われます。

1) デプロイ前に EAR ファイルを変更するユーティリティを提供する。2) すべての構成設定を別の場所に保管します。3) すべての構成設定をデータベースに保存します。コンテナーを介してデータベースにアクセスし、JNDI を介して公開された接続を提供します。

しかし、確立されたベストプラクティスはありますか?

それが欠けている場合、どのアプローチが効果的でしたか?

ありがとうカーティス