Zenn
Open2

Eclipse + JBoss でWebアプリをデプロイ

Hiroki_blogHiroki_blog

以下では、先ほどの英語の内容をすべて日本語でまとめ直しました。JBoss EAP 7.4をEclipse（JBoss Tools）からCLIでのデプロイと同様に動作させる手順や注意点を記載しています。

EclipseのデプロイとCLIのデプロイの違い

1. CLIによる「管理型デプロイ」

jboss-cli.bat（または管理コンソール）を使ってWARをデプロイすると、JBoss EAP内部のコンテンツリポジトリ（standalone/data/content/配下）にWARの内容が配置されます。これはいわゆる「管理型デプロイ」で、サーバが自動的にWARをアップロードし、デプロイを管理します。

2. Eclipse（JBoss Tools）による「アンマネージド・デプロイ」

一方、EclipseのJBoss Toolsからサーバにパブリッシュ（デプロイ）を行うと、既定ではstandalone/deployments/フォルダにWARを置き、.dodeployまたは.deployedなどのマーカー・ファイルを使ってサーバに知らせる「アンマネージド・デプロイ（deployment scanner方式）」が使われます。さらに、プロジェクトが**展開済み（exploded）**ディレクトリとして置かれる場合も多く、CLIのデプロイとは異なる挙動になることがあります。

このように、CLIデプロイ（管理型）とEclipseデプロイ（アンマネージド）の方式が異なるため、CLIで動作するアプリがEclipse経由で動かない場合があります。

目標

Eclipseからのデプロイでも、CLIと同じようにアプリが正常動作するようにする。具体的には、

  1. EclipseからWARファイルを作成・配置する際に、サーバが認識してアプリが正しく起動するようにする。
  2. OASIS.warなどのWARを配置したら、ローカルホストで正常にアプリが見られる状態（CLIと同じ状態）にする。

対応策・設定手順

手順1. Eclipseのデプロイ設定で「圧縮されたWARファイルとしてデプロイ」する

Eclipseの「Servers」ビューで、JBoss EAP 7.4のサーバ定義をダブルクリックするとサーバエディタが開きます。そこに「Deployment」（または「Publish」）などのタブがあり、デプロイ方式を変更できます。

  1. Deploy projects as compressed archives（日本語の場合は「プロジェクトをアーカイブ（WAR/JAR）としてデプロイ」などの文言）

    • これを有効にすると、Eclipseは展開（exploded）フォルダではなく、圧縮されたWARファイルとしてstandalone/deploymentsに配置するようになります。
    • これにより、OASIS.war/というディレクトリではなく、OASIS.warという1つのファイルがサーバに配置されます。
    • デプロイ時には、JBoss側がOASIS.warを読み込み、.deployedや.dodeploy等のマーカーを扱って自動的にデプロイしてくれます。CLIとほぼ同様の振る舞いになります。

  2. 「JBoss deploy folder」を使うかどうかの確認

    • 既定ではEclipseがstandalone/deploymentsを使うよう設定されているはずですが、もしEclipseのワークスペース内部の別フォルダを使う設定になっている場合は、standalone/deploymentsに切り替えておきましょう。
    • これにより、CLIのときと同じパス（<JBOSS_HOME>/standalone/deployments）にWARが配置されます。

  3. サーバを再パブリッシュ

    • 上記の設定後にサーバを「Clean」または「Publish」し直す、あるいはEclipseでサーバを一旦削除して再度追加するなどの操作を行い、正しい設定が反映されるようにします。
    • 事前に、standalone/deploymentsに残っているOASIS.war/フォルダや古い.failedなどのマーカーを削除しておくとスムーズです。

この方法によって、Eclipseからも.jar/.warをアーカイブ形式で配置するようになります。結果としてJBoss EAP側もCLIデプロイと同じように処理できるため、ローカルホストでのアクセスがうまくいく可能性が高まります。

手順2. Eclipseでのプロジェクト設定を再確認する

Eclipse（WTP）のプロジェクト構成が正しくWebモジュール（Dynamic Web Module）として設定されていないと、WARに必要なファイルが含まれないなどの問題が生じます。
以下の点をチェックしてください。

  1. プロジェクト・ファセット

    • Eclipseのプロジェクトのプロパティ「Project Facets」内で「Dynamic Web Module」が有効になっているか。
    • バージョン（Servlet 4.0など）が正しく設定されているか。

  2. Deployment Assembly（配備アセンブリ）

    • プロジェクトのプロパティ→「Deployment Assembly」で、ソースフォルダやリソース、必要なライブラリが正しくWARに含まれるよう設定されているか。
    • もしMavenで依存ライブラリを管理している場合は、Mavenとの統合（M2E）でpom.xmlの依存関係を正しく認識し、配備アセンブリに反映される設定になっているか。

  3. 手動ビルドと同じWARができるか

    • CLIでdeployするときに使っているWAR（target/OASIS.warなど）と、Eclipseで自動生成されるWARが同じ内容かを確認します。
    • Eclipseの設定が不十分だと、ファイルが足りない/余計なものが入っているなどのズレが起こり、デプロイに失敗することがあります。

手順3. 既存のMavenビルド済みWARをEclipseから「Mark as Deployable」する（必要に応じて）

もしCLIでデプロイしているWARが外部のMavenビルド（mvn clean packageなど）で作られているのであれば、EclipseのJBoss Toolsで以下の操作を行うことも可能です。

  1. Mavenビルドをしてtarget/フォルダにOASIS.warを生成
  2. Eclipse上で、そのWARファイルを右クリック → “Mark as Deployable”（または「配備対象としてマーク」など）
  3. EclipseのServersタブで当該サーバを右クリック → “Add and Remove…”（または「追加と削除」）で、そのWARをサーバに追加

こうすることで、CLIで使うのと全く同じOASIS.warをEclipse経由でJBossに配置できます。これなら、WARの中身が同じなのでCLIと動作が一致しやすくなります。

手順4. デプロイ後にアクセス確認

  • JBossのコンソールやログでOASIS.warが正常にデプロイされたというメッセージが出ているかを確認します（OASIS.war deployed successfully.など）。
  • ブラウザで http://localhost:8080/OASIS/ のようなURLにアクセスし、アプリが表示されるか確認します。

以上の手順を踏めば、EclipseからのデプロイでもCLIと同じようにアプリが起動・アクセス可能になるはずです。

補足: 管理APIを使うデプロイもあるが…

JBoss Toolsは、ローカルサーバ向けには「デプロイメントスキャナ方式（=アンマネージドデプロイ）」を使うのが標準です。
もし「リモートサーバ」に対してデプロイする場合や、特殊な設定でEclipseが管理APIを使う場合もありますが、基本的には圧縮WARを作ってdeployments/に置く設定で問題なく運用できます。

ただし、どうしてもCLIのアップロード（管理API）を同じプロセスで呼びたい場合、MavenのWildFlyプラグイン（wildfly-maven-plugin）で mvn wildfly:deploy のようなコマンドを実行し、EclipseからMaven目線でビルド＆デプロイする方法もあります。しかし、この場合はEclipseの自動デプロイ機能とは別にMavenゴールを呼ぶ形になるため、通常は「圧縮WARをデプロイ」設定にしたほうが手軽です。

まとめ

  1. Eclipseのサーバ設定で「WARを圧縮形式で配置」できるようにする。
    • “Deploy as a compressed archive” オプションを有効にする。
  2. プロジェクト自体を正しくDynamic Web Module化して、WARに必要なファイルが含まれているかチェック。
  3. 同じWARファイル（CLIで使うもの）をEclipseにも認識させる方法として、「Mark as Deployable」も有効。
  4. サーバをクリーン＆パブリッシュし直した後に、standalone/deploymentsの中にOASIS.warファイルができているか、ログに成功メッセージがあるかを確認。
  5. ブラウザで http://localhost:8080/OASIS/ へアクセスして動作をチェック。

これらの手順を踏むことで、EclipseからデプロイしてもCLIデプロイ時と同様にJBoss EAP上で正常に稼働するはずです。もしまだうまくいかない場合は、ログ（server.log）のエラーメッセージや、Eclipseのコンソールに出力される情報を詳細に確認してください。

Hiroki_blogHiroki_blog

了解です。Eclipse上のMavenで実行した場合にNexusリポジトリへのアクセスが401エラーで失敗し、CLIからの実行では成功するという状況を踏まえて、EclipseのMaven設定をCLIと同じように動作させる方法を調査します。

Eclipse上のMavenでNexus認証を通すための設定（settings.xml、Maven installation、ローカルリポジトリパス、認証情報の保存方法など）に注目して解決策をまとめてお伝えします。少々お待ちください。

EclipseでのMaven設定とNexus認証エラーの対処

1. EclipseのMaven環境（バージョン・環境変数）の確認

まず、Eclipse上で使用されているMavenがCLI（コマンドライン）と同じものであることを確認します。Eclipseでは**組み込み版(Embedded)**のMavenがデフォルトで使われる場合がありますが、CLIで使用している外部Mavenを Eclipse に認識させることが可能です (java - Where is the settings.xml used by maven in the Spring Tool Suite? - Stack Overflow)。Eclipseのメニューから「Window -> Preferences（設定）-> Maven -> Installations」を開き、現在使用中のMavenインストールを確認してください。CLIで使用しているMavenのバージョン・パスがここに表示されていない場合、**Add...**ボタンでそのインストール先ディレクトリを追加し、チェックを入れてデフォルトに設定します (java - Where is the settings.xml used by maven in the Spring Tool Suite? - Stack Overflow)。これにより、EclipseのMaven実行がCLIと同じMavenバージョン・設定を参照するようになります（M2_HOME や Global settings も一致します）。

(Spring Integration with Eclipse Using Maven | Programmatic Ponderings)Eclipseの「Preferences -> Maven -> Installations」設定画面の例。デフォルトでは組み込みMavenのみがリストされていますが、**Add...**で外部のMavenインストールを追加しチェックを入れることで、Eclipseで外部Mavenを使用できます（図ではApache Maven 3.1.1を追加）。このように外部Mavenを指定することで、CLI環境と同一のMaven実行環境を共有できます。

また、JAVA_HOME などの環境変数についても確認が必要です。Eclipse自体は起動時のシステム環境変数を引き継ぎますが、例えばWindowsではシステムの環境変数にJAVA_HOMEやM2_HOMEが設定されているか、macOSの場合はGUI起動時に環境変数が適用されているか注意します。Eclipse上でMavenを実行する際、コンソールに表示される「Maven home」や「Java version」をチェックし、CLI実行時の mvn -v の出力と一致していれば問題ありません。万一一致しない場合は、Eclipseの設定で適切なJDKを選択し（「Java -> Installed JREs」等で）、必要ならEclipseの.iniに環境変数を指定してください。

2. 認証情報の取り扱い（NexusのID/Passwordに関する注意）

次に、Nexusの認証情報（ユーザID/パスワード）の扱いについて確認します。通常、Maven（ひ dol CLIでもEclipseでも）settings.xmlの<servers>セクションに設定したクレデンシャルを使用します。EclipseのM2Eプラグインも内部的にはMavenを呼び出しているだけなので、特別な設定をしなくてもsettings.xmlに正しくID/Passwordが書かれていればCLI同様に認証ヘッダを送信するはずです (What to do when Sonatype Nexus Repository returns '401')。したがって、401エラーが出る場合は「Eclipse上でMavenが認証情報を送っていない（認識できていない）」可能性があります (What to do when Sonatype Nexus Repository returns '401')。

考えられる原因の一つは、パスワードの暗号化方式の違いです。Mavenでは settings-security.xml に設定したマスターパスワードで <servers> 内のパスワードを暗号化・復号できますが、Eclipse経由で実行する際にこれがうまく機能していないケースがあります。実際、あるユーザはArtifactory（Nexus類似のリポジトリ）の認証で、Maven標準の暗号化パスワードを使うとうまくいかず、ArtifactoryのWeb UI上で表示される「暗号化済みパスワード」文字列をそのままsettings.xmlに記載したところEclipseでも認証が通ったと報告しています (Eclipse Community Forums: Eclipse Process Manager (Stardust) » M2eclipse error 401 unauthorized)。これはArtifactory固有の例ですが、裏を返せばEclipse上ではMavenの暗号化パスワードが正しく復号されず認証ヘッダが送られていなかった可能性があります。対策として、まずCLI同様に ~/.m2/settings-security.xml が存在するか確認し、Eclipse実行ユーザからそのファイルが読める状態にします。それでも改善しない場合、一時的に平文のパスワードをsettings.xmlに置いて試すか、リポジトリ側で提供されるトークン方式の資格情報（例えばNexusではユーザーごとのトークン認証）を利用することも検討してください (Eclipse Community Forums: Eclipse Process Manager (Stardust) » M2eclipse error 401 unauthorized)。基本的にEclipse固有で認証情報を別途設定する項目はなく、settings.xmlでの管理となる点を押さえておきましょう。

3. Eclipseによる settings.xml の読み込み確認

次に、Eclipseが正しくsettings.xmlを読み込んでいるかを確認します。EclipseのMaven設定でユーザ設定ファイルを指定しているとのことですが、念のため以下をチェックします。

  • User Settingsのパス設定: Eclipseの「Preferences -> Maven -> User Settings」画面で、User SettingsファイルとしてCLIと同じsettings.xmlのパスが設定されているか確認します（通常はユーザホーム直下の ~/.m2/settings.xml）。もしここがデフォルトの場所（空欄の場合はデフォルトパスを指す）と異なるパスを使っている場合は、Browseボタンから正しいファイルを指定してください (Why is Eclipse/Maven project not picking up the values from settings.xml? - Stack Overflow)。設定後、「Update Settings」（設定の再読み込み）ボタンがあれば押して反映させ、必要ならEclipseを再起動します。この設定により、依存解決やビルド時にそのsettings.xmlに書かれたミラー設定やサーバ認証情報が確実に使われるようになります。

  • 正しいsettings.xmlが参照されているかテスト: Eclipse上でMavenビルドを実行する際に、エラーログに実際参照しているリポジトリURLや設定ファイルパスが出力されることがあります。mvn -X install（デバッグログ有り）をEclipseから実行し、どのsettings.xmlを読んでいるか確認してみるのも一案です。もしEclipseが別のsettings.xml（例: デフォルト場所のファイル）を読んでいる場合、想定した認証情報が見つからず401になる可能性があります。

  • デフォルトsettings.xmlの存在: ごく稀なケースですが、Eclipseが指定したsettings.xmlを読まずデフォルトの~/.m2/settings.xmlを参照してしまう不具合報告もあります (Return code is: 401, ReasonPhrase: Unauthorized)。実際あるユーザは、意図した設定が読まれていないことに気付き、デフォルトの~/.m2/settings.xmlにダミーの設定を配置することで対処したと述べています (Return code is: 401, ReasonPhrase: Unauthorized)。このような問題は最新のEclipseでは起きにくいと思われますが、もしEclipseの挙動が怪しい場合は同様の方法（デフォルトパスにも同じ設定ファイルを置いてみる）で改善するか試してみてもよいでしょう。

4. Nexusリポジトリにアクセスするための設定手順

以上を踏まえ、Eclipse上のMavenビルドでNexusからの依存ダウンロード（mvn install）が401エラーなく成功するための手順をまとめます。

  1. 外部Mavenの使用（バージョン統一）: EclipseのMaven実行環境をCLIと統一します。前述のとおり、Preferencesの Maven -> Installations でCLIと同じMavenを追加・選択してください (java - Where is the settings.xml used by maven in the Spring Tool Suite? - Stack Overflow)。例えばApache Mavenをインストール済みなら、そのフォルダを追加しExternal Mavenとしてチェックを入れます。 (Spring Integration with Eclipse Using Maven | Programmatic Ponderings)これによりビルド時の挙動や使用されるsettings.xml、ローカルリポジトリの場所もCLIと完全に同じになります。もし何らかの理由でEmbedded Mavenを使う必要がある場合でも、少なくともバージョン差異がないよう最新のEclipse/M2Eにアップデートしてください。

  2. ユーザ設定（settings.xml）の適用: Eclipseに正しい設定ファイルを認識させます。Preferences -> Maven -> User Settingsで、User Settings Fileに該当のsettings.xmlを設定します (Why is Eclipse/Maven project not picking up the values from settings.xml? - Stack Overflow)。既に同一パスが表示されていれば問題ありませんが、念のため「Open File」で中身を確認し、認証情報やミラー設定が含まれていることを確かめます。設定を変更した場合は「Update Settings」を実行し、Eclipseを再起動して反映させます（プロジェクトのMaven設定にも反映されるようにするため）。

  3. 認証サーバIDの確認: settings.xml内の<server>エントリの<id>が、実際にアクセスするNexusリポジトリのIDと一致していることを確認します。例えばPOMや設定で内部リポジトリIDがnexus-privateとなっているなら、settings.xmlの<servers>セクションでも <id>nexus-private</id> としてユーザ名/パスワードを記述する必要があります (Return code is: 401, ReasonPhrase: Unauthorized)。IDが不一致だと正しい資格情報が見つからず401になります（この点はCLIでも同様なので、CLIで成功している場合はおそらく合致しているはずですが念のため）。併せて、Nexus上のアカウントがそのリポジトリへの読み取り権限を持っているかも確認してください。

  4. パスワード設定の見直し（必要な場合のみ）: もし上記まで設定してもうまくいかない場合、パスワードの書き方を疑います。まずはsettings.xmlに平文のパスワードを直接記載して試します（セキュリティ上問題ない範囲で一時的に実施）。これでEclipseからもダウンロードできるようなら、暗号化の問題だったことになります。その場合、Mavenの暗号化機能を再設定するか、Nexusがサポートする別の資格情報（例えば長期トークンなど）を利用してみてください (Eclipse Community Forums: Eclipse Process Manager (Stardust) » M2eclipse error 401 unauthorized)。なお、平文パスワードを使う場合は他者に漏れないよう取扱いに注意してください。

  5. プロジェクトのMaven設定を更新: Eclipseで該当プロジェクトを右クリックし、「Maven -> Update Project...」を実行してMaven設定をリフレッシュします。これにより、依存関係の再解決が行われ、更新されたsettings.xmlや認証情報が反映されます。最後に「Run As -> Maven Install」を実行し、依存のダウンロードやビルドがエラーなく完了することを確認してください。CLIで成功していたビルドであれば、上述の設定が正しく行われていればEclipse上でも同様に成功するはずです。

補足: もしそれでも401エラーが解消しない場合、Eclipse組み込みMavenの不具合の可能性も考えられます。過去の報告では、特定バージョンのEclipse内蔵Mavenコネクタにおいて認証付きリポジトリへのアクセス時に問題が発生し、CLIでは成功するのにEclipse経由だと401になるケースがありました (java - eclipse maven deploy war to nexus OSS Access denied Error code 401, Unauthorized - Stack Overflow)。この場合、上記手順1のように外部Mavenを利用することで問題を回避できるほか、起動オプションに -Daether.connector.basic.threads=1 を付与するワークアラウンドが紹介されています (java - eclipse maven deploy war to nexus OSS Access denied Error code 401, Unauthorized - Stack Overflow)（後者はマルチスレッド転送のバグ回避策です）。基本的には外部Mavenを使う設定にしておけばこうしたバグの影響も受けにくくなるため、安全策として外部Maven利用が推奨されます。

以上の点を確認・設定することで、Eclipse上でのmvn install実行時にもNexusリポジトリからのライブラリダウンロードが401 Unauthorizedエラーなく成功するようになるでしょう。各手順を丁寧に見直し、CLIとの挙動差を埋めていくことで問題解決を図ってください。

参考資料: EclipseでのMaven設定に関する公式/コミュニティ情報や類似事例 (java - Where is the settings.xml used by maven in the Spring Tool Suite? - Stack Overflow) (Eclipse Community Forums: Eclipse Process Manager (Stardust) » M2eclipse error 401 unauthorized) (Return code is: 401, ReasonPhrase: Unauthorized) (java - eclipse maven deploy war to nexus OSS Access denied Error code 401, Unauthorized - Stack Overflow)なども併せて参照しました。