問題タブ [java-ee-7]

参照: 公式 GlassFish 4.0 docs/javaee-tutorial Java EE 7

まず、destination-type of: topic から始めましょう。GlassFish 4.0 チュートリアルのセクション「<strong> 46.4 高性能でスケーラブルな JMS アプリケーションの記述」:

このセクションでは、JMS API を使用して、大量のメッセージを確実に処理できるアプリケーションを作成する方法について説明します。

サブセクション「<strong> 46.4.2 共有永続サブスクリプションの使用」:

SharedDurableSubscriberExample.java クライアントは、共有永続サブスクリプションの使用方法を示しています。これは、共有永続サブスクリプションが、永続サブスクリプションの利点 (クライアントがアクティブでない場合でもサブスクリプションはアクティブなままである) と共有コンシューマーの利点 (メッセージの負荷を複数のクライアント間で分割できる) をどのように組み合わせるかを示しています。

「<strong> 46.4.2.1 ShareDurableSubscriberExample および Producer クライアントを実行するには」に従ってこの例を実行すると、キューの宛先タイプに関する前の例と同じ効果/機能が得られます。 6.2 To Run the AsynchConsumer and Producer Clients」の5以降を指し、2 つのコンシューマー ターミナル ウィンドウと 1 つのプロデューサー ターミナル ウィンドウを使用してわずかに変更します。

はい、セクション「<strong> 45.2.2.2 Publish/Subscribe Messaging Style」には次のことが記載されています。

JMS API は、コンシューマがアクティブでない間に送信されたメッセージを受信する永続的なサブスクリプションをアプリケーションが作成できるようにすることで、この要件をある程度緩和しています。永続サブスクリプションは、キューの柔軟性と信頼性を提供しますが、クライアントは多くの受信者にメッセージを送信できます。

.. とにかくセクション「<strong> 46.4 高パフォーマンスでスケーラブルな記述..」 の例はキュー スタイルです - コンシューマごとに 1 つのメッセージ:

トピック サブスクリプションに追加された各メッセージは、キューに追加された各メッセージが 1 つのコンシューマーによってのみ受信されるのと同様に、1 つのコンシューマーによってのみ受信されます。

正確な技術的な答えは何ですか: この例では、トピックで Shared-Durable-Consumer を使用することが想定されており、「<strong> High Performance and Scalable JMS Application」と Asynchronous- の使用で言及されている理由コンシューマーがキューに入っていますか?

JSON 参照ライブラリ ( http://docs.oracle.com/javaee/7/api/javax/json/package-summary.html ) を使用していくつかのコードを書き始めたところ、単純な問題が発生しました。シンプルだが「醜い」解決策。

JsonObjects は、Map クラスによってサポートされているにもかかわらず、「不変」です。これは、それらを変更してはならないことを意味します。

オブジェクトを非常に動的に構築したい、たとえば、配列を取得してそれに要素を追加する、完全な「読み取り/書き込み」モデルを作成したいと考えています。

それでも、JsonObjectBuilder は「書き込み専用」インターフェイスを実装しているように見えます。そこに物を入れることはできますが、それらを読み取ることはできません (マップなどをサブクラス化しませんか?)。後で追加したい場合にそれを追跡するため（配列ビルダーを「読み取る」方法がないため...）

そのため、読み取り専用と書き込み専用の 2 つのインターフェイスがあり、唯一可能な変換は、書き込み専用から読み取り専用への変換であり、元に戻す方法はなく、JSON 構造を読み書きする方法はありません。

非常に明白な何かが欠けているように感じます...

明らかな「汚い」解決策は、もちろん、データを独自の構造に保存し、ビルド時にJSONビルダーに変換することですが、これは、データを変更して渡す必要があるJSONのレシーバーにはあまり役立ちません. 私のオブジェクトとそのオブジェクトの間の双方向インターフェース、または読み取り専用のjsonを（再帰的に）変換してビルダーに戻し、プロセスでそれを変更するコンバーター...

私は何が欠けていますか？JSON の独自の表現を作成し、それを RO / WO モデルに出し入れする必要があるのはなぜですか?

（はい、私はグーグルを試しましたが、私が思いついたものは何も役に立ちませんでした。それは私をさらに混乱させました...）

取得して Java オブジェクトに変換するのに約 400 ミリ秒かかるリモート リソースを取得しています。このオブジェクトは、JAX-RS Web サービス (オブジェクト所有者) への大量の要求で参照される可能性があります。ID/ハッシュでオブジェクトを保存し、後でそれを取得できる組み込みのキャッシュメカニズムはありますか (ハッシュマップのように、3600 秒後にリソースを期限切れにする方法があります)。

私が見た： https://blogs.oracle.com/cwebster/entry/caching_static_resources_in_glassfish

それは有望に見えますが、リンクされた ExpiresFilter はもはや存在せず、他の多くのメソッドがこのメソッドに依存している間に JAX-RS メソッドを呼び出すリモートシステムの問題を解決するだけです (したがって、メソッドは Java 内で直接呼び出されます)。

ArrayList のリストがあり、各 arraylist は日付と文字列で構成されています。配列リストの日付に従ってリストをソートしたい。答えを探してみましたが、オンラインで見つけることができません。ほとんどの例は、オブジェクトのリストを日付でソートしています。助言がありますか？

ps。リストを返す前にリストをソートしたい

Java EE 7 を使用しています。アプリケーション スコープのCDI Beanに JPAEntityManagerを挿入する適切な方法を知りたいです。インスタンスはスレッドセーフではないため、アノテーションを使用して注入することはできません。すべての HTTP リクエスト処理の開始時に作成され、HTTP リクエストが処理された後に閉じられると仮定しましょう。2つのオプションが頭に浮かびます：@PersistanceContextEntityManagerEntityManager

1. への参照を持つ要求スコープの CDI Bean を作成し、EntityManagerその Bean をアプリケーション スコープの CDI Bean に注入します。

この例でEntityManagerは、 が作成されると が作成され、が破棄さRequestScopedBeanれると が閉じられます。RequestScopedBeanこれで、インジェクションを抽象クラスに移動して、ApplicationScopedBean.

2. のインスタンスを生成するプロデューサを作成し、そのインスタンスをアプリケーション スコープの CDI Bean にEntityManager注入します。EntityManager

この例ではEntityManager、HTTP リクエストごとに作成される もありますが、 ?を閉じるのはどうでしょうか。EntityManagerHTTP リクエストが処理された後も閉じられますか? @PersistanceContextアノテーションが container-managed を注入することは知っていEntityManagerます。これはEntityManager、クライアント Bean が破棄されると が閉じられることを意味します。この状況でのクライアント Bean とは何ですか? ApplicationScopedBeanアプリケーションが停止するまで決して破棄されない ですか、それともEntityManagerProducerですか? 何かアドバイスはありますか？

アプリケーション スコープ Bean の代わりにステートレス EJB を使用して、EntityManagerアノテーション@PersistanceContextで注入できることはわかっていますが、それは重要ではありません :)