問題タブ [stateless-session-bean]

@Stateless2 つのインターフェイス (リモートとローカル) を実装する Bean があります。@LocalBeanインターフェイスなしのビューで Bean にアクセスするための注釈も追加しました。

@Injectこの理由で、JBoss AS7 クイックスタートのこの例から取ったものを使用します。

CDI の「リソース プロデューサー」パターンを使用して、エンティティ マネージャーの昔ながらの @PersistenceContext インジェクションを CDI スタイルのインジェクションに「エイリアス」します。これにより、アプリケーション全体で一貫した注入スタイル (@Inject) を使用できます。

今、私は以前に使用しました：

EJB では問題なく動作します。しかし、@Inject注釈を使用すると、次のエラーが発生します。

WELD-001408 注入ポイント [[field] @Inject private ejb.WeatherDataBean.entityManager] で修飾子 [@Default] を持つタイプ [EntityManager] の満たされていない依存関係

クラス Resources を定義する方法は次のとおりです。

エンティティ マネージャーを挿入しようとすると、このエラーが発生するのはなぜですか?

編集: @LightGuard からの要求に応じて、注釈を参照するために使用しているパッケージを追加しています。

1. WeatherDataBeanには次のものがあります。

   /li>

2. リソースには次のものがあります。

   /li>

ejbとjpaコントローラーを使用したいのですが、netbeansではコントローラーが自動的に生成されます...セッションBeanステートレスであるクラス（UniversidadServiceEJB）からjpaコントローラーを呼び出そうとすると、プロジェクトをデバッグし、UserTransactionとEntityManagerFactoryが正常に作成されますただし、jpaコントローラー（UniversityJpaController）でメソッドutx.beginを呼び出すと、次の例外がスローされます。

java.lang.IllegalStateException：操作は許可されていません。

com.sun.enterprise.transaction.UserTransactionImpl.checkUserTransactionMethodAccess（UserTransactionImpl.java:146）at com.sun.enterprise.transaction.UserTransactionImpl.begin（UserTransactionImpl.java:162）at controller.UniversidadJpaController.create（UniversidadJpaController.java:47 ）at services.UniversidadServiceEJB.create（UniversidadServiceEJB.java:40）at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）at sun.reflect.NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl.java:57）at sun.reflect.DelegatingMethodAccessorImpl.inv DelegatingMethodAccessorImpl.java:43）at java.lang.reflect.Method.invoke（Method.java:601）at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod（EJBSecurityManager.java:1052）at org.glassfish.ejb .security.application.EJBSecurityManager。comb（EJBSecurityManager.java:1124）at com.sun.ejb.containers.BaseContainer.invokeBeanMethod（BaseContainer.java:5388）at com.sun.ejb.EjbInvocation.invokeBeanMethod（EjbInvocation.java:619）at com.sun.ejb .containers.interceptors.AroundInvokeChainImpl.invokeNext（InterceptorManager.java:800）at com.sun.ejb.EjbInvocation.proceed（EjbInvocation.java:571）at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke（SessionBeanInterceptor.java:49 ）at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）at sun.reflect.NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl.java:57）at sun.reflect.DelegatingMethodAccessorImpl.invoke（DelegatingMethodAccessorImpl.java:43）atjava.lang.reflect。 com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept（InterceptorManager。java：861）at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext（InterceptorManager.java:800）at com.sun.ejb.EjbInvocation.proceed（EjbInvocation.java:571）at com.sun.ejb.containers .interceptors.SystemInterceptorProxy.doAround（SystemInterceptorProxy.java:162）at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke（SystemInterceptorProxy.java:144）at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）at sun.reflect .NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl.java:57）at sun.reflect.DelegatingMethodAccessorImpl.invoke（DelegatingMethodAccessorImpl.java:43）........。container.interceptors.SystemInterceptorProxy.doAround（SystemInterceptorProxy.java:162）at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke（SystemInterceptorProxy.java:144）at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）atsun。 Reflect.NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl.java:57）at sun.reflect.DelegatingMethodAccessorImpl.invoke（DelegatingMethodAccessorImpl.java:43）........。container.interceptors.SystemInterceptorProxy.doAround（SystemInterceptorProxy.java:162）at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke（SystemInterceptorProxy.java:144）at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）atsun。 Reflect.NativeMethodAccessorImpl.invoke（NativeMethodAccessorImpl.java:57）at sun.reflect.DelegatingMethodAccessorImpl.invoke（DelegatingMethodAccessorImpl.java:43）........。invoke（DelegatingMethodAccessorImpl.java:43）........。invoke（DelegatingMethodAccessorImpl.java:43）........。

SessionBeanクラスは次のとおりです。

そして、jpacontrollerクラスは次のとおりです。

そして、永続性ユニットは次のとおりです。

何が問題なのですか？..ありがとうございました...

私のプロジェクトの中心にあるビジネス ロジックの一部は、リンクされたデータの検索を実行する必要があります。現在、私はこの部分をこのようなシングルトン セッション Bean を使用して実装しています (SPARQL は、リンクされたデータを使用して構築された RDF モデルのクエリ言語です)。

この EJB は、クライアントによって指定された構文、結果の総数、およびその他のメタデータを含む文字列形式のモデルを含む、より快適なオブジェクトSparqlEndpointに変換する別の EJB によってアプリケーションの他の部分に公開されます。EJB はシンプルで、クライアントが使用するローカル インターフェイスを備えています。これらのクライアントには、JSF マネージド Bean と、それを SOAP および RESTful Web サービスとして公開する 2 つの EJB が含まれます。ResultSetSearchResultSparqlEndpoint@Stateless

これは私の頭に浮かんだ最も合理的なアーキテクチャですが、それが正しいかどうかを知る必要があります。現在行っているように、Bean を使用しSingletonてコアを実装する必要がありますか?それとも、Statelessセッション Bean の方が適切ですか? データベース接続の初期化には通常、少なくとも数秒かかります。これは NoSQL であり、トランザクションをサポートしていないことに注意してください。この Bean に write メソッドなどを追加する予定はありません。他の EJB がステートレスであることは正しいですか? (データベースへの書き込みを実行する) インデックス作成エンジンを別の EJB として公開したい場合、どのように実装すればよいですか?

前もって感謝します。

私はそのようなステートレスローカルBeanを持っています:

したがって、この Bean を使用すると、次の例外が発生しました。

重要：

次のように、(同じ EAR 内の) Web サービスからこの EJB を使用します。

そして、Web サービスのクラスでデータソースを取得しようとすると、正常に動作します。

編集：

別の考慮事項: REMOTE インターフェイスを使用すると機能します。しかし、ローカルインターフェースで使いたいです。

私は Weblogic 10.3.5 を使用しています。私のデータソースは作成され、他のアプリケーション (JNDI によって直接取得) で正常に動作します。

ステートレス セッション Bean 内でのインスタンス変数の使用が人気のあるディスカッション トピックであることは知っており、既にそれらのいくつかを読んでいますが、このトピックで特に必要なのは、アプリケーションの実際の適切な設計です。

私のエンタープライズ アプリケーションは、特定のイベントで起動するいくつかのステートレス Bean で構成されています。そのようなイベントでは、いくつかのタイマーも起動し、特定のものを追跡したい（たとえば、元のイベントに固有のデータベースに挿入された新しいデータ）。

ただし、複数のタイマーを異なる間隔、イベント ID、およびサーバー IP で手動で呼び出す小さなテストを行ったところ、すべてのタイマーで期待どおりの動作が得られませんでした (一部のタイマーはタイムアウトにならないなど)。

上記のソースは必要な使用法に適していますか、それとも別の方法で設計/実装する必要がありますか? はいの場合、いくつかのオプションを提案していただけますか?

私は現在、データベースと対話するためにステートレス セッション Bean を呼び出す Web アプリケーションを扱っています。私の質問は、そのようなアプリケーションが同じセッション Bean を呼び出して、後者がデータベースへのアクセスに使用する必要があるエンティティ マネージャーを選択できる方法についてです。

現時点では、さまざまな Jboss インスタンスを起動し、さまざまなポートでリッスンすることでこの状況を管理しており、各インスタンスで同じセッション Bean プールをデプロイしており、1 つ以上の Web アプリケーションが同じデータベースを処理する必要があります。つまり、すべての Jboss インスタンスには、特定の数の Web アプリケーション、永続化ユニット(persistence.xml in META-INF jar containing the @Entity's)、およびセッション Bean のプールがすべて ear 内に含まれています。主な弱点がどこにあるのかは自明です。より多くの異なるデータベースを処理する必要があり、多くの Jboss インスタンスを維持する必要があり、リソースの理由だけでなく、主に持続可能ではありません。

私の最後の質問は、注入された EntityManager のみが異なる、異なる Web アプリケーション呼び出しセッション Bean をデプロイするためのベスト プラクティスは何ですか?

前もって感謝します

Stfn

EJB 3.0 ステートレス セッション Bean で汎用インメモリ オブジェクト キャッシュを作成するには、どのプログラミング パターン (および製品) を使用する必要がありますか?

静的メンバー変数またはシングルトン パターンを使用すると、キャッシュが一貫している必要がない場合、クラスター化された環境で副作用が発生しますか?

キャッシュされるデータは、JDBC データソース (JPA はオプションではありません) および Web サービスから取得されます。キャッシュされるデータの量は数メガバイトです。キャッシュは非常に高速な読み取りを提供する必要があるため、アプリケーションが使用している JVM 内でソリューションを実行することをお勧めします。

私はJavaEEを初めて使用するので、私の質問は非常に基本的なものかもしれません。ステートレスセッションBean（単純化）を使用して次のRESTWebサービスを構築しました。

それは魅力のように機能します。URL経由でアクセスでき、JSONを返します。問題は、すべてのコンパウンドを取得するためのある種のモデルとしてこのSession Beanを使用する必要がある、プレーンJavaで記述されたプログラムの別の部分があることです。

問題は、このSession Beanを永続コンテキストの外にある場所で初期化すると、データベースにアクセスするためのEntityManagerを認識しないことです。私は信じている。

どうしたらいいのかわからない。コードの離れた部分でクラスListResourceを初期化し、EntityManagerの依存性注入を機能させることはできますか？または、どういうわけか永続コンテキストを取得してから、このセッションBeanを初期化しますか？

私はそれが理にかなっていることを願っています。私が説明するのは複雑な問題です。

私はJavaでアプリケーションを作成していて、そこにいくつかのRESTWebサービスがあります。私のアプリケーションの構造は次のとおりです：http：//cl.ly/L7Pv/o

RESTWebサービスクラスはステートレスセッションBeanです。それは魅力のように機能します。しかし、写真の赤いクラスは、そのRESTリソースも使用したいと考えています。

私が知っている限りでは、依存性注入とアノテーション@EJBを使用することはできません。JNDIルックアップを使用する必要があると思います。ドキュメント：http ：//docs.oracle.com/javaee/6/tutorial/doc/gipjf.html

しかし、今はこのJNDIルックアップの書き方がわかりません。私はこれらの2つを試しました：

私は何が間違っているのですか？そもそもこれは正しいアプローチですか？

ありがとうございました

サービスファサードは通常、ステートレスセッションBeanとして実装されます。つまり、サービスファサードが返す可能性のあるエンティティは、すぐに切り離されます。これにより、サービスファサードビジネスメソッドの結果として返されるエンティティは、すべての内部を熱心にフェッチする必要があると思います。熱心なフェッチがない場合、サービスクライアントはその内部にアクセスできないためです。私はこれが正しいかどうか、そして特定の状況でより適切かもしれない他の方法があるかどうかを知りたいです。

ありがとうございました