問題タブ [spray-routing]

私はspray-servlet（サーブレットコンテナとしてTomcat 8を使用して）とspray-routing.

WAR をデプロイするたびにserviceActor、メッセージを受け取ります。このメッセージは特定のパスに送られ、常に同じパスで、常に 1 回です。の死んだ手紙の俳優ですsender。system

このメッセージがどこから来ているのかわかりません。この問題のデバッグにご協力いただければ幸いです。

スプレーは、headerValueByName を介して特定の名前を持つ 1 つのヘッダーの抽出のみをサポートします。以下のスプレーコードスニペットで「whatever」という名前のすべてのヘッダーを取得するにはどうすればよいですか? ヘッダーを抽出する何らかの方法が必要です!?

スプレー初心者です。私は、Python、JQueryなどのいくつかの（私にとっては）奇妙なプログラミング言語を扱ってきました...それらを使用すると、少なくとも一部のコードセグメントが何をするかを理解できました。残念ながらSprayでは、簡単なコードすら読んで理解できません。

次の単純なコードブロックを読むのを手伝ってくれませんか（コードが何をするのかを言葉で説明してください）。

注:私が知っている非常に高レベルの、これは url パラメーターを選択し、それらを一緒に追加します。しかし、私が望むのは、他の誰かに教えることができるように、このコード ブロックのクリスタルを明確に理解することです。HNil, Directive1, Directive1, ::私にとって奇妙なものがあります。

私のルーティングは次のようになります。

私の問題は、エラーコードがオフになっていることです。

無効なドキュメントを含む POST を /api/persons/new にクエリすると、InvalidEntity 応答コードが返されるはずですが、405: Method not allowed, supported: GET が返されます。

/api/login と同じです。

エンティティが正しい場合、正しいルートが実行されます。

/api/persons/invalidnumber に対して DELETE を発行すると、404 ではなく 405 が返されます。

これらのルートに対して GET を実行すると、404 が返されます。最後のルートが getFromResource を実行しようとしている可能性があります。

ルートから「早期復帰」を強制する方法はありますか? そのようなentity(as[LoginRequest]) { ... } ~ failWithPreviousRejection

認証用のディレクティブが 1 つあるとします。認証後、ログインしたいと思います。これは私がこれまで行っていることです：

そのため、認証が必要になるたびに 2 つのディレクティブを使用するのではなく、それを 1 つのディレクティブに変換したいと考えています。

フラット マップを使用してみましたが、authenticate が Directive1 を返し、logRequestResponse が Directive0 を返すため、うまくいかないようです。

ということで map で試してみたのですが、私のロギングマグネット機能には入らないようです。

リクエスト オブジェクトとレスポンス オブジェクトも必要なので、logme を直接呼び出すこともできません。

異なるディレクティブ タイプを返す 2 つのディレクティブを持つ新しいディレクティブを作成する方法はありますか? ありがとう。

スプレーを使用して REST API を構築しています。JSON データ型の 1 つが再帰的です。

HttpService でルートを完了すると、次のエラーが発生します。

HttpService は次のようになります。

その関数はコンテナのリストを返しますがcomplete、GET機能しています。ただし、 のコメント アウトされた行はget機能せずpost、エラー メッセージに見られるように、 のコンテナを暗黙的に変換することもできません。コンテナーを暗黙的に動作させ、再帰構造を維持するにはどうすればよいですか?

スプレー HTTP サーバーの使用例を見ると、サーバーがリクエストを同時に処理するのではなく、順番に処理することが非常に簡単になっているようです。これは、例が一度に 1 つの要求を処理するアクターとして実装されたルーティング オブジェクトを示しているためです (facepalm? ** )。これはよくある問題のようです。

たとえば、以下では、/work1 にアクセスすると要求が非同期に処理されますが、/work2 については残念ながら他のすべての要求がブロックされます (たとえば、/work2 がデータベース内の Cookie からトークンを認証するためにビジー状態になる必要があるとします)。

ルーティングに到達する前に実行が分岐する場所で、spray.routing を使用する方法はありますか?

** 通常、ルーティングはステートレスな操作であるため、ルーターとアクタを作成してもメリットはないようです。

私が使用した他のすべてのWebサーバーでは、TCP接続を受け入れた直後に、ハンドラープロセスまたはスレッドへの接続の分岐制御がより賢明に（IMO）発生します。（私が思うに）これにより、接続を受信できる速度が最大になり、意図しないブロックのリスクが最小限に抑えられます。少なくとも、ルーティングでの意図しないブロックが完全に回避されます。

アップデート：

@rahilbが提案したように

そして次のように呼び出します：

... work1 または work2 のいずれかで、まだ約 3 秒かかります。

リクエスト時に動的に作成される比較的大きなファイルを提供する Web サービスを開発しています。私の場合、これは多数のファイルを含む ZIP アーカイブ ファイルですが、他の種類の動的に作成されたファイルでも同じ問題が発生すると思います。

問題は、ディスク上に ZIP ファイルを作成することを避けたいということです。むしろ、それを HTTP 応答に直接ストリーミングするだけです。私が考えた 1 つの方法は、チャンク ストリーミングを使用することです。これは、ストリーミング アクターが一度にチャンクを送信し、次のチャンクを送信する前にレスポンダーからの確認を「待機」することを意味します。( https://github.com/spray/spray/blob/release/1.1/examples/spray-routing/on-spray-can/src/main/scala/spray/examples/DemoService.scalaの例をsendStreamingResponse参照)

残念ながら、私が見つけることができるすべての例は、ストリームが事前に定義されている場合にそれを行う方法を示していますが、データのストリームが他の将来に準備されている場合にこれにアプローチする最良の方法はよくわかりません.

私の場合、Futureファイルをフェッチし、java.util.zip.ZipOutputStream. しかし、Spray でのストリーミングのしくみは逆です。ストリーミング アクターは、データの準備ができたときにデータをプルする必要があるためです。すべてのデータをストリームにプッシュすることはできません。

これはおなじみの使用例ですか?それに取り組む最善の方法は何ですか?

私のサービスルート：

私の仕様:

ブラウザーでテストした場合、GET ルートと POST ルートの両方が適切に機能しています。POST はテストでも動作します。GET ルートの何が問題になっていますか? なぜそれはテストできないのですか？このようなエラーの原因と回避方法は?

更新： プロパティベースではないテストも「グリーン」であるため、scalacheckと関係があるようです：