この記事の要点
Eclipse でプロジェクトを Tomcat プロジェクトとして認識させる方法 Sysdeo プラグイン版: プロジェクト → プロパティ → Tomcat → Tomcat プロジェクトにチェック WTP 版 (Eclipse for Java EE): プロジェクト・ファセット → 動的 Web モジュールを有効化 「サーバーに追加または除去できる…」エラーもここから派生

 

本稿はeclipseにてプロジェクトをTomcatプロジェクトとして認識させる方法を説明します。Sysdeo Tomcat プラグインを導入している環境向けの手順です。Eclipse for Java EE / Eclipse IDE for Enterprise Java Developers の WTP（Web Tools Platform）を使う場合は別途下の節を参照してください。

Sysdeo Tomcat プラグインの場合

この節はSysdeoを導入済みの旧環境を保守するための手順です。WTPのServersビューとは別の仕組みであり、同じ設定画面が現行Eclipseにも必ずあるとは限りません。プラグインの導入版・対応Tomcat・実際に操作するインスタンスを確認してください。Sysdeoの現行互換性や実画面は本稿では検証していません。

eclipse上のパッケージ・エクスプローラーにてプロジェクトを右クリック → プロパティ → Tomcat → Tomcatプロジェクトにチェックマークを入れます。

コンテキストの設定も同じ画面でできます。コンテキスト名（URLのパス部分）と、Web App ディレクトリのルート（通常は WebContent や src/main/webapp）を指定します。

設定後にやること

• プロジェクトを右クリック → Tomcat プロジェクト → コンテキスト定義を更新
• 管理しているTomcatインスタンスを、その環境で決めた方法で再起動する。元の例の$CATALINA_HOME/bin/startup.shは外部Unix起動の例で、IDE内のTomcat起動ボタンと無条件に置き換えない。既に起動中のTomcatへ別の起動を重ねない
• ブラウザで http://localhost:8080/コンテキスト名/ を確認

Eclipse WTP（Web Tools Platform）を使う場合

WTP（Web Tools Platform）のサーバー連携を使う環境では、次の手順を確認します。導入したEclipseパッケージとプラグインによってメニューの有無・名前が異なるため、SysdeoのTomcatプロパティと混同しないでください。

1. サーバービューを開く

ウィンドウ → ビューの表示 → その他 → サーバー > サーバー を開きます。

2. Tomcat サーバーを登録

サーバービューを右クリック → 新規 → サーバー → Apache → 使用するTomcatのバージョンを選択 → インストールパス（$CATALINA_HOME）を指定。

3. プロジェクトを動的Webプロジェクト化

既存のJavaプロジェクトでは、対応する環境で右クリック → 構成 → Convert to Faceted Formを使い、その後プロパティ → Project FacetsでDynamic Web ModuleとJavaの設定を確認します。既にファセット化されている場合は変換を繰り返す必要はありません。変換だけでWebアプリのコードや配置設定がすべて完成するわけではありません。

Targeted Runtimesで利用するTomcatを選び、Project Facetsの版との互換性を確認します。互換性のないランタイムは選択できないことがあります。表示されない場合はランタイムの登録状況から確認し、.settingsのXMLをむやみに手編集しないでください。Servlet APIやJavaの版を無条件に最新へ上げる対処も避けます。

4. サーバーに追加

登録したTomcatサーバーを右クリック → 追加と除去 → プロジェクトを追加 → 完了。その後、対象モジュールの公開状態を確認し、必要ならPublish（公開）します。追加できること、配置が完了すること、アプリが正常に起動することは別なので、Consoleの起動・配置エラーも確認してください。

うまく認識されないとき

• プロジェクトプロパティに Tomcat タブが無い: Sysdeo未導入・無効・非対応などを確認。WTPには同じタブがあるとは限らないため、使用する連携方式を先に確認する
• 404 が返る: コンテキスト名・Web Appディレクトリに加え、公開状態、アプリの起動失敗、要求したファイルやサーブレットのマッピング、アクセス先のポートを確認。404だけで一つの原因に断定しない
• クラスが反映されない: ビルドエラーと公開結果、配置先インスタンス、起動中の版を確認。WebアプリではクラスをWEB-INF/classesやWEB-INF/libのJARから読み込むが、IDEのビルド出力先を常に直接WEB-INF/classesへ変更する必要があるわけではない
• Tomcat のポート競合: まず既存プロセスと二重起動を確認。必要なら対象インスタンスのserver.xmlやWTPのサーバー設定で使用ポートを確認・変更し、アクセスするURLも合わせる。関係ないTomcatの設定を変えない

関連

• conf/server.xml: Tomcatのサーバー設定。Contextを直接記述する方式はあるが、Tomcat公式は通常それを推奨していない。WTP/プラグイン管理の設定を先に確認し、手編集と自動生成を混ぜない
• web.xml: サーブレット・フィルタ定義
• 元の例のTomcat標準ページhttp://localhost:8080/は、ROOTアプリが配置されている場合の確認先。標準ページがない構成もあり、ルートの404だけではTomcat起動失敗と判断できない。対象アプリの実在するURLと起動ログで確認する

認識・公開・アクセスを順に切り分ける

止まっている段階	確認するもの	次の確認
追加候補にプロジェクトが出ない	Dynamic Web Module、対象ランタイム、互換性、Web用プラグイン	ファセットとランタイムを整えてから追加候補を確認
追加できるが変更が出ない	ビルド結果、公開状態、Webリソースと依存JARの配置	実際に公開されたアプリと起動ログを照合
起動後に404になる	ホスト・ポート・context root・対象リソースやマッピング	存在するファイルと存在しないURLを区別

例えばcontext rootがsampleでindex.htmlを公開した場合、確認先はhttp://localhost:8080/sample/index.htmlです。ここで8080とsampleは例示値で、実際の設定を使います。/だけを開いても対象アプリの公開成功は確認できません。ソースのWebContentやsrc/main/webappと、Tomcat上の公開ディレクトリは同じ場所とは限りません。

変更前後の確認と注意

1. 使用する連携方式、Tomcat/Java/Servletの版、context root、ポートを記録する。
2. 対象サーバーの起動構成を確認する。CATALINA_HOMEはインストール先、CATALINA_BASEは実行インスタンスで、別の場所の場合がある。
3. ビルド・公開・アプリ起動の順に結果を確認し、失敗した段階のログを読む。
4. 公開した既知のリソースへアクセスし、編集内容が反映されたことを確認する。

ワークスペースやTomcat設定の削除、.settingsの一括書換えは通常の対処にしません。変更前の設定を保存し、ログ・設定を共有する場合は認証情報や個人情報を伏せてください。起動ログの確認はTomcatの起動ログが表示されない時の確認も参照できます。

検証範囲と資料

Tomcat 9.0.122 / Java 21の隔離環境で、ROOTアプリなしでもsample/index.htmlは200、ルートと存在しないリソースは404になることを確認しました。これはTomcat側のアクセス確認であり、Eclipse/WTPやSysdeoの実画面・公開処理全体を検証したものではありません。使用する版のメニュー・設定値を確認してください。

一次資料（2026年10月確認）: Eclipse: Dynamic Web project、Eclipse: Targeted Runtimes、Tomcat: Context、Tomcat: Deployment。