JavaWebアプリケーションを一部のアプリケーションサーバーまたは単純なWebコンテナ（この場合のように）に正しくデプロイするには、Webアプリ（Webモジュールとも呼ばれます）に特定の構造が必要です。Webモジュールの最上位ディレクトリは、アプリケーションのドキュメントルートです。
Webモジュールの構造は次のとおりです。
<url-pattern>これで、web.xmlファイルで定義するのは、一部のサーブレットの論理/仮想パスにすぎません。繰り返しになりますが、これはサーブレットクラスの物理的な場所への実際のパスではなく、論理的なパスです。必要に応じて作成します。
OK、今度は正しい構造のWebアプリケーションをwebappsディレクトリに配置する必要があります。たとえば、上の図では、アセンブリルートはwebappフォルダーを表しています。したがって、そのフォルダーを直接取得するか、WAR（WebアプリケーションARchive）を作成してwebappsディレクトリのすぐ下に配置することができます。Webアプリにディレクトリがあり、そのディレクトリにいくつかのWebアプリがあるわけではありません。すべてのWebアプリは、webappsディレクトリのすぐ下にある必要があります。
したがって、あなたの場合、webappフォルダーの名前がshlaaの場合は、そのフォルダーをのすぐ下に配置する必要がありますwebapp。限目。
次に、公式のJavaEEドキュメントから引用します。
URLをWebコンポーネントにマッピングする
リクエストを受信すると、WebコンテナはどのWebコンポーネントがリクエストを処理するかを決定する必要があります。Webコンテナは、リクエストに含まれるURLパスをWebアプリケーションとWebコンポーネントにマッピングすることでこれを行います。URLパスには、コンテキストルートと、オプションでエイリアスが含まれます。
http://host:port/context-root/alias
コンポーネントエイリアスの設定
エイリアスは、リクエストを処理する必要があるWebコンポーネントを識別します。エイリアスパスは、スラッシュ（/）で始まり、文字列または拡張子付きのワイルドカード式（* .jspなど）で終わる必要があります。Webコンテナは、*。jspで終わるエイリアスを自動的にマップするため、ファイル名以外の名前でページを参照する場合を除いて、JSPページのエイリアスを指定する必要はありません。
あなたの場合、あなたのウェブアプリへのURLは
http://localhost:8080/shlaa
Jetty wikiドキュメント（ Jetty / Howto / SetContextPathto）からqouteします。
WebAppProviderの使用
WebAppProviderの役割は、$ {jetty.home} / webapps /ディレクトリでデプロイ可能なアプリケーション（* .warなど）を探し、それらをファイル名と同じ名前のコンテキストにデプロイすることです。たとえば、WebAppProviderは${jetty.home}/webapps/MyApp-2.4.warをコンテキスト/MyApp-2.4にデプロイします。コンテキスト/にデプロイされる特別なroot.war予約語もあります。これは最も簡単な展開メカニズムですが、展開の詳細に対する制御を犠牲にします。
長い話を短くするには、Webアプリをwebappsディレクトリのすぐ下に配置してすべてを機能させます。-については、<url-pattern>お好きなパターンを自由に定義してください。
注：実際には、Jettyを構成する方法はいくつかあります。つまり、XML構成だけではありません。詳細については、 Jettyの構成を参照してください。
Java™サーブレット仕様バージョン3.0からの引用：
第12章
リクエストのサーブレットへのマッピング
12.1URLパスの使用
クライアント要求を受信すると、Webコンテナはそれを転送するWebアプリケーションを決定します。選択したWebアプリケーションには、要求URLの先頭と一致する最長のコンテキストパスが必要です。URLの一致する部分は、サーブレットにマッピングするときのコンテキストパスです。次に、Webコンテナは、以下で説明するパスマッピング手順を使用してリクエストを処理するサーブレットを見つける必要があります。サーブレットへのマッピングに使用されるパスは、リクエストオブジェクトからのリクエストURLからコンテキストパスとパスパラメータを差し引いたものです。以下のURLパスマッピングルールが順番に使用されます。最初に成功した一致が使用され、それ以上の一致は試行されません。
コンテナは、リクエストのパスとサーブレットのパスが完全に一致するものを見つけようとします。一致が成功すると、サーブレットが選択されます。
コンテナは、最長のパスプレフィックスとの一致を再帰的に試行します。これは、パス区切り文字として「/」文字を使用して、パスツリーを一度にディレクトリごとにステップダウンすることによって行われます。最長の一致によって、選択されるサーブレットが決まります。
URLパスの最後のセグメントに拡張子（.jspなど）が含まれている場合、サーブレットコンテナは、拡張子の要求を処理するサーブレットとの照合を試みます。拡張子は、最後の「。」の後の最後のセグメントの一部として定義されます。キャラクター。
前の3つのルールのいずれもサーブレットの一致をもたらさない場合、コンテナは要求されたリソースに適切なコンテンツを提供しようとします。アプリケーションに「デフォルト」サーブレットが定義されている場合は、それが使用されます。多くのコンテナは、コンテンツを提供するための暗黙のデフォルトサーブレットを提供します。コンテナでは、大文字と小文字を区別する文字列比較を使用して照合する必要があります。
12.2マッピングの仕様
Webアプリケーションデプロイメント記述子では、次の構文を使用してマッピングを定義します。
パスマッピングには、「/」文字で始まり、「/*」サフィックスで終わる文字列が使用されます。
'*。'で始まる文字列 プレフィックスは拡張マッピングとして使用されます。
空の文字列（ ""）は、アプリケーションのコンテキストルート、つまりフォームのリクエストに正確にマッピングされる特別なURLパターンですhttp://host:port/<contextroot>/。この場合、パス情報は'/'であり、サーブレットパスとコンテキストパスは空の文字列（ ""）です。
'/'文字のみを含む文字列は、アプリケーションの「デフォルト」サーブレットを示します。この場合、サーブレットパスはリクエストURIからコンテキストパスを引いたものであり、パス情報はnullです。
- 他のすべての文字列は、完全一致にのみ使用されます。
あなたの名前の例。
Webアプリケーション名はmapappです（これはアプリケーションルートです）。CommentController.doにを介してアクセスする必要があります
http://localhost:8080/mapapp/shlaa/CommentController.do
次に（ディレクトリ構造などの他のすべての要件が満たされている場合）、web.xmlに次のように記述します。
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<servlet>
<servlet-name>Comment Controller</servlet-name>
<servlet-class>com.example.CommentController</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Comment Controller</servlet-name>
<url-pattern>/shlaa/CommentController.do</url-pattern>
</servlet-mapping>
</web-app>
上記のurl-patternの最初のスラッシュ（/）は、コンテキストルート/コンテキストパス（この場合はmapapp）を表します。
このように動作します。
ここにいくつかの便利なリンクがあります。
Java EE 5チュートリアル：
Java EE 6チュートリアル：
桟橋
これがお役に立てば幸いです。
アップデート
Jetty固有の構成については、次のリンクを参照してください：
Webアプリを特定のポートでのみ応答させる方法