このチュートリアルに従ったと仮定します。
古き良き信頼できるApache httpdを意味する場合、作成したプロジェクトをそのサーバーにデプロイすることはできません。作成するのは Java Enterprise アプリケーション (より具体的には WAR、Webapplication ARchive) であり、そのタイプのアプリケーションをデプロイできるサーバー - もちろん Glassfish だけでなく、Apache Tomcat、jetty、またはJava Enterprise Edition サーバーのいずれか
あなたが Apache httpd について話していること、Glassfish が異なる目的を果たすまったく異なる獣であると仮定すると、Glassfish は実際に http 経由でコンテンツを提供できますが、それよりもはるかに多くの機能が含まれています。Java に関する上記のウィキペディアのリンクを参照してください。より多くのリンクとポインターについては EE を参照してください。
編集: Tomcat のようなサーブレット コンテナーや、GlassFish のような Java EE サーバーを Apache サーバーの "内部" で実行することはできません。これは、mod_php を使用して Apache の "内部" で php を実行する場合と同じですが、Apache httpdサーバーは外向きで、基本的に呼び出しをバックエンド Java サーバーに転送します。この結果を得るにはいくつかの手法があります。最も一般的なのは、Tomcat についてはこちら、Glassfish についてはこちらで説明されているように、おそらく mod_jk を使用することです。または、mod_proxy をセットアップすることもできます。これは、SOでこれら 2 つのシナリオを比較したものです。
いずれにせよ、Tomcat や Glassfish の前面に Apache を配置することは必ずしも必要ではありませんが、Web サイトが部分的に php や別の apache-hosted スクリプト言語で記述されたハイブリッド コンテンツを提供している場合や、サーブレット コンテナーを使用してサービスを提供することを避けるために役立つ場合などに、必要になる場合があります。大量の静的コンテンツであり、多くの場合、それらの最強のポイントではありません。多くのアプリケーションでは、Tomcat または Glassfish にすべてのコンテンツを提供させて、mod_proxy または mod_jk と両方のサーバーの二重管理によってもたらされる余分な複雑さを回避することはまったく問題ありません。