問題タブ [spray-json]

ケースクラスをmongoDbオブジェクトとしてシリアル化するためにSalatライブラリを使用しています。私の Item.scala ファイルは次のようになります。

今、私はそれを使用して、Spray HTTP 経由で Item エンティティを Json として投稿しています。次のように呼び出したいと思います。

私が提供しない場合は、生成されたIDが提供されることを願っています。

ただし、curl コマンドを呼び出した後、エラーが発生します。

リクエスト コンテンツの形式が正しくありません: オブジェクトに必要なメンバー '_id' がありません

オプションを作成せずに _id フィールドをオプションとしてマークする方法はありますか (このフィールドは常に設定されます)、カスタム JsonFormat を定義して、自分でオブジェクトを (逆) シリアル化しますか?

この投稿を読みました: https://stackoverflow.com/a/10820293/1042869、しかし、 _id フィールドの多くのケースを取得したため、それを行う他の方法があるかどうか疑問に思っていました。「ケースクラス定義でそのフィールドにデフォルト値を与えることができるので、フィールドがjsonにない場合はデフォルト値が割り当てられます。」というコメントもありましたが、ここでわかるようにうまくいかないようです。

ベスト、マルシン

スプレーを使用して Scala で汎用 HTTP クライアントを作成しようとしています。クラス定義は次のとおりです。

オブジェクトutils.AllJsonFormatsには次の宣言があります。すべてのモデル形式が含まれています。同じクラスが「反対側」で使用されます。つまり、API も作成し、同じフォーマッターをスプレー缶とスプレー json で使用しました。

もちろん、そのオブジェクトには、models.api.Space、models.api.Failure、models.api.Success のシリアル化の定義があります。

タイプは問題ないようです。Spaceつまり、ジェネリックメソッドに を受け取って返すことを伝えると、Spaceエラーは発生しません。しかし、メソッド呼び出しにいずれかを入れると、次のコンパイラ エラーが発生します。

タイプ Spray.httpx.unmarshalling.Unmarshaller[Either[models.api.Failure,models.api.Success]] の証拠パラメーターの暗黙的な値が見つかりませんでした。

私の期待は、spray.json.DefaultJsonProtocol 内、つまり、spray.json.StandardFormts 内のいずれかが暗黙的にカバーされることでした。

以下は、私の HttpClient クラスであり、一般的であることが最善です: 更新: より明確で反復可能なコード サンプル

上記では、アンマーシャラーが解決されていない場合でも問題が発生します。助けていただければ幸いです..

ありがとう。

Option[DateTime]パラメーターを持つケース クラスを、API で提供できるスプレー json オブジェクトに変換したいと考えています。スプレー json を使用して、私はカスタム JsonFormat を持っています。

しかし、私は得る：

コンパイルしようとすると、何をしようとしても、DateTime オブジェクトを文字列に変換できないようです。たとえば、電話をかけようとするtoStringと、

ここで私が書いているスプレー スカラ デモに触発された API クラスがあり、スプレー ルートで JSON オブジェクトとして Person をレンダリングします。

問題は、marshal(bob) が次のような JSON を返すことです。

次のように「年齢」なしで JSON をレンダリングする必要があると想像してください。

これはどのように達成できますか？私が考えていることの 1 つは、Scala には、別のオブジェクトのプロパティのサブセットであるオブジェクトを作成する方法があるということです。あるいは、スプレー json は、サーバーの応答に追加されるべきではないプロパティをマーシャリングしないための特定のサポートを持っているのでしょうか?

スプレーライブラリを見つめながら、Facebook Graph API にリクエストを送信しようとしました。

主な問題は、応答の contenttype が Content-Type: text/javascript; charset=UTF-8 期待されるものではないことですapplication/json

私のリクエストの何が問題なのですか？

Spray解析などのコンテンツタイプに大きく依存しているように.

スプレー json を介してRescueTime APIとやり取りしようとしています。結果の形式は次のとおりです。

現時点では、適切なケース クラスをハッシュ化しようとしています。ここに私がこれまでに持っているものがあります:

これはすべて問題ありませんが、コンパイル時に次のscalac結果が得られます。

発散する暗黙の展開についての私の理解は、せいぜいラフです。大まかに、暗黙の検索にはサイクルがあります。私が理解しているように、暗黙的は暗黙的なパラメーターを期待するインポートtoJsonから来ています。これは、オブジェクトによって提供されます。ただし、この特定の暗黙のパラメーターがサイクルを導入する理由は、私にはわかりません。1 つの理論は、適用される変換が暗黙的なパラメーターの解決に干渉している可能性があるというものですが、それはただの予感です。spray.json._JsonWriterMyJsonProtocoltoJsonAny

どんな助けでも大歓迎です。

Spray-json で Map[String, Any] をシリアル化するにはどうすればよいですか? 私は試します

それは言いCannot find JsonWriter or JsonFormat type class for scala.collection.immutable.Map[String,Any]ます。

ルーティングディレクティブを完全に使用するときに、カスタム JsonFormat 書き込みメソッドを呼び出す方法を見つけようとしています。ヘルパー関数の jsonFormat セットで作成された JsonFormat は正常に動作しますが、完全な JsonFormat を定義すると呼び出されません。

そして、次のようなルート：

ログを追加すると、ErrorJsonFormat.write メソッドが呼び出されないことがわかります。

影響は次のとおりで、取得しようとしている出力と実際に取得するものを示しています。Record インスタンスが Record("something", "somethingelse", EntityNotFound) だったとしましょう

実際

意図されました

私はcomplete(record)、適切な JsString フィールドを作成する書き込みメソッドを指定する暗黙的なオブジェクト ErrorJsonFormat に依存する Record の暗黙的な JsonFormat を使用することを期待していました。代わりに、シリアル化の指示を無視しながら、提供された ErrorJsonFormat を認識しているようです。

implicit val record2Json = jsonFormat3(Record)明示的に置き換える必要のない解決策が必要だと思いますimplicit object RecordJsonFormat extends JsonFormat[Record] { ... }

だから私が求めていることを要約すると

• Record のシリアル化が ErrorJsonFormat 書き込みメソッドの呼び出しに失敗するのはなぜですか (代わりに何をしますか?)以下で回答します
• まだ使用している間に私の期待に応える方法はありcomplete(record)ますか?

編集

スプレー json ソース コードを掘り下げると、jsonFormat 一連のメソッドを定義しているように見える sbt-boilerplate テンプレートがあります: https://github.com/spray/spray-json/blob/master/src/main/boilerplate/スプレー/json/ProductFormatsInstances.scala.template

そして、それからjsonFormat3に関連する製品は次のようです:

このことから、jsonFormat3 自体はまったく問題ないように思われます (productElement2Field をトレースすると、ライターが取得され、write が直接呼び出されます)。問題はcomplete(record)、 JsonFormat がまったく関与せず、何らかの形でオブジェクトを交互にマーシャリングすることです。

したがって、これはパート 1 の答えのようです: Record のシリアル化が ErrorJsonFormat 書き込みメソッドの呼び出しに失敗するのはなぜですか (代わりに何をしますか?)。他の方法で完全にマーシャリングするため、JsonFormat は呼び出されません。

残りの問題は、JsonFormat が存在する場合はそれを使用する完全なディレクティブにマーシャラーを提供できるかどうか、それ以外の場合はデフォルトで通常の動作になるかどうかです。基本的なケース クラスのシリアライゼーションについては、通常、デフォルトのマーシャラーに頼ることができることに気付きました。しかし、この例のように複雑なトレイト/ケース クラスのセットアップを取得した場合、適切な応答を得るには JsonFormat を使用する必要があります。理想的には、JsonFormat を呼び出す必要があるのではなく、ルートを作成する人がデフォルトのマーシャラーである状況を知る必要があるために、この区別を明示する必要はありません。言い換えれば、指定された型を次のように記述する必要があるかどうか、complete(someType)またはcomplete(someType.toJson)間違っていると感じるかどうかを区別する必要があります。