問題タブ [spray]

私はこのScala/Sprayのすべてに本当に慣れていません。いくつかのテストで、parameters関数を使用してGetリクエストからパラメーターを取得することができました。ただし、POSTリクエストから送信されたいくつかのパラメーターをリクエストの本文でフェッチしようとしています。パラメータ関数はこれらの値をフェッチできないようです。

例として、この値「name = john＆lastname=smith」をPOSTリクエストの本文から取得しようとしています。これらの値を取得するための最良のオプションは何ですか？

ありがとうございました

注： 残念ながら、この質問は終了しましたが、他の誰かが同じ質問をした場合に備えて、この質問を維持しようとしています。

私は、モバイルデバイスと既存のWebサービスの間に位置するScalaでのサービスを開発するための優れたソリューションを探していました。

実行可能なオプションの現在のリストは次のとおりです。

• フィナグル
• 噴射
• 青い目
• アッカ
• Play2 Mini
• フィルタリングされていない
• リフト
• 煙
• スカラトラ

おそらくそこにはもっと多くのオプションがあります。どちらを使用するかをどのように決定しますか？良いScalaミドルウェアの選択の特徴は何ですか（駄洒落を許してください;-)。TypeSafe Scalaスタックの一部であるAkkaに行きたいのですが、Finagleのようなものには豊富なライブラリのセットがあり、配管がとても簡単です。スプレーは見栄えが良く、使いやすいです。

アドバイス、洞察、経験をいただければ幸いです。そこにいる誰かが、共有しても構わないこれらのいくつかの経験を持っているに違いないと確信しています。

アップデート：

この質問が再開されることを望んでいます。この質問に対する良い答えは、新しいスケーラターが関連する落とし穴を回避するのに役立ちます。

更新2：

これらは、この質問をして以来の私自身の経験です。

Finagle-私はプロジェクトにFinagleを使用しましたが、それは堅実です。

スプレー-私の最新のプロジェクトでは、スプレーを使用していますが、非常に満足しています。最新のリリースはAkka2に基づいて構築されており、Spray-canライブラリを使用して直接実行できるため、Webサーバーが不要になります。スプレーはフレームワークではなくライブラリのセットであり、非常にモジュール化されています。Learn about Spray：REST on Akkaビデオは素晴らしい概要を提供し、Cakesolutionsのこのブログは本当に素晴らしい開発アプローチとアーキテクチャを示しています。

更新3：

人生はかなり速く動きます。たまに立ち止まって見回さないと、見逃してしまうかもしれません。-Ferris Bueller

最近では、選択が簡単になっています。私の謙虚な意見では、スプレーは戦いに勝ちました。次のAkkaHTTPになるために、Akkaに統合されています。私は現在、複数のプロジェクトでスプレーを使用していますが、これは私が今まで出会った中で最も素晴らしく、最もサポートされているソフトウェアであると正直に言うことができます。

これは最初の質問に答えるものではありませんが、少なくとも、ほとんどの場合、スプレーが最良の選択であると思われる理由をある程度示しています。非常に柔軟性があり、ブロッキングがなく、非常に安定しています。クライアント側とサーバー側の両方のライブラリと優れたテストキットがあります。また、これらの統計を見て、パフォーマンスに関するアイデアを入手してください。Webフレームワークのベンチマーク

過去数か月で、私と同僚は、プッシュ通知を iPhone デバイスにディスパッチするためのサーバー側システムの構築に成功しました。基本的に、ユーザーは RESTful Web サービス ( Spray-Server、最近HTTP レイヤーとしてSpray-canを使用するように更新されました) を介してこれらの通知を登録し、ロジックは Akka のスケジューラーを使用して、将来のディスパッチのために 1 つまたは複数のメッセージをスケジュールします。

私たちが構築したこのシステムは、単純に機能します。1 秒間に数百、場合によっては数千の HTTP リクエストを処理でき、1 秒あたり 23,000 の速度で通知を送信できます。送信側のアクター (したがって、Apple とのより多くの接続) と、使用する Java ライブラリ ( java-apns ) で実行する最適化が行われる可能性があります。

この質問は、Right(tm) を行う方法に関するものです。私の同僚は、Scala とアクター ベースのシステム全般に精通しており、アプリケーションが「純粋な」アクター ベースのシステムではないことを指摘しており、その通りです。私が今疑問に思っているのは、それを正しく行う方法です。

現時点では、HttpServiceサブクラス化されていない単一の Spray アクターがあり、HTTP サービス ロジックの概要を説明する一連のディレクティブで初期化されています。現在、非常に単純化された、次のようなディレクティブがあります。

さて、これが正しければ、アクターからの「応答を待つ」ことは、アクターベースのプログラミングでは禁止されています (さらに、!! は非推奨です)。requestそれを行う「正しい」方法は、オブジェクトをpersisterメッセージでアクターに渡しrequest.complete、バックエンドから生成された ID を受信したらすぐに呼び出すことだと私は信じています。

これを行うために、アプリケーションのルートの 1 つを書き直しました。アクターに送信されるメッセージでは、リクエスト オブジェクト/参照も送信されます。これは、次のように機能するようです。

ここでの私の主な懸念は、requestオブジェクトを「ビジネス ロジック」、この場合は永続化プログラムに渡しているように見えることです。パーシスタは、 call などの追加の責任と、request.completeそれが実行されるシステムに関する知識 (つまり、それが Web サービスの一部である) を取得するようになりました。

このような状況を処理する正しい方法は何でしょうか?永続化アクターは、それが http サービスの一部であることを認識せず、生成された ID を出力する方法を知る必要がありません。

リクエストは引き続き永続化アクターに渡す必要があると考えていますが、永続化アクターが request.complete を呼び出す代わりに、SchedulePersisted(request, businessObjectId)単に を呼び出す HttpService アクター (メッセージ) にメッセージを送り返しますrequest.complete("/businessObject/%s".format(businessObjectId))。基本的：

私はこのアプローチで正しい軌道に乗っていますか?

spray-serverサブクラスHttpService化して receive メソッドをオーバーライドしてもいいですか、それともそのように壊れますか? (アクターのサブクラス化や、認識されていないメッセージを「親」アクターに渡す方法についてはわかりません)

最後の質問は、requestアプリケーション全体を通過する可能性のあるアクター メッセージでオブジェクト/参照を渡すことです。

こんにちは、こちらのスプレー ページにサンプル 2/デモ 2 と同じ jquery grow 関数があるかどうか疑問に思っていました。

http://labs.adobe.com/technologies/spry/samples/effects/grow_sample.html

ほとんどのサイト効果は jquery を使用しているため、スプレーを使用したくありません。

ありがとう！

Spray-jsonライブラリは、基本的なScalaタイプをtoJsonメソッドで拡張します。Any基になるタイプにそのようなヒモがあるJsValue場合は、をに変換したいと思います。私の最善の試みはうまくいきますが、冗長です：

理想的には、私はこのようなもの（不可能）を好むでしょう：

強化されたすべてのタイプを列挙せずにこれを行う方法はありますか？

常に JSON 応答を返す RESTful サービスを照会する必要があります。何度か連絡する必要がありますが、常に前回のリクエストから学んだ情報がいくつかあります。Akka2、Scala、Jerkson、Spray-Can を使用しています。

私の現在のアプローチは機能しているようですが、見た目が悪く、すべてをネストする必要があります。チェーンなどに関して利用可能なテクニックがいくつかあるはずだと読みましたが、現在のユースケースにそれらを適用する方法がわかりませんでした。

これが私が話しているコードです：

模様が見えると思います。REST サービスに連絡して読み取り、成功したら JSON ケース クラスに解析し、情報を抽出してから次の呼び出しを行います。

ここでの構造は 2 レベルの深さしかありませんが、3 番目のレベルも追加する必要があります。

読みやすくするためにこれを改善するためのテクニックはありますか、それともこれに固執することはできますか? さらに情報が必要な場合は、喜んで提供いたします。ここで完全なコードを見ることができます: https://github.com/daschl/cachakka/blob/f969d1f56a4c90a929de9c7ed4e4a0cccea5ba70/src/main/scala/com/cachakka/cluster/actors/InitialConfigLoader.scala

ありがとう、マイケル

私はスプレーでプロジェクトを開始しており、サンプルアプリケーションを実行するために (プロジェクトを開始するために) wiki をフォローしようとしています。しかし、私はそれらを動作させることができません。このドキュメントが書かれてから、スプレーの sbt 設定はかなり変更されたようです。

次のように拒否された場合、指示が機能しません。sbt "project spray-example-simple" shell

Build.scala（同じフォルダー内に）が、この名前のプロジェクトが含まれています：

だから私は、なぜ私が sbt に拒絶されたのか、かなり心配している。sbt project他のいくつかのフォルダーでコマンドを実行しようとしましexamplesたが、同じエラーが発生しました。私は何が欠けていますか？これは私にはよくSet current project to default-951202見えませんが、それを修正する方法がわかりません。

前もって感謝します。

私はAPIを提供するためにScalaとSprayの学習に取り組んでおり、Scalaコードに変更を加えるたびに、Akkaサーバーを再起動する必要があります（現在は、起動してから実行していますcontainer:start）。私はこれを間違っていますか？

スクリプト言語から来ているので、変更がすぐに反映されるのを見るのに慣れていますが、これはコンパイルされているので、これは現実のことだと思いますか？

スプレーを使用していくつかの RESTful サービスを構築しようとしています。必要なディレクティブを作成する方法を理解しました。しかし、私が抱えている問題は、作業している「リソース」に戻る URL を確実に生成する方法です。ここでは、RESTful API (つまり、API を介して参照されるサーバー側オブジェクト) に使用される「リソース」という用語を使用します。

私はドキュメントを調べましたが、Java の意味での「リソース」(つまり、クラスパス内のデータ ファイル) の言及を除いて、これに関する参照は見つかりませんでした。

確かに、「/items/127」をサーバー側のリソースにマップするディレクティブを作成できます。しかし、Spray で (少なくとも安全で自動的な方法で) どうすればよいかわかりません。それは、サーバー側のリソースを指定してそのような URL を生成する方法です。url_forFlask フレームワークに似たものを探しています。

今のところ、これを行うための関数を書いています。しかしもちろん、それらは DRY ではないため脆弱です (つまり、URL の生成にスプレー ルーティングの知識を使用しません)。

何か不足していますか？