開発目的で、シングルトンBeanにダミーのデータリポジトリを実装しました。シングルトンBeanのコンストラクターはダミーデータを作成し、ダミーデータを取得、挿入、更新、および削除するメソッドがあります。
単体テストを行うと、挿入および更新されているオブジェクトが、挿入および更新されたのと同じ状態で取得できること(つまり、プロパティごとの同等性)を確認すると、単体テストに合格します。このテストでは、シングルトンBeanを通常のオブジェクトとして、つまりコンストラクターを介してインスタンス化します。@RequestScoped
シングルトンBeanをJSFバッキングBean(Beanの作成をEJBコンテナに任せる)に注入して実際に使用すると、データアイテムを更新し、続いてそのIDで取得した後、更新が失われ、古いフィールド値が失われるようです。使用されています。したがって、Beanはコンテナの内外で同じように動作しません。それでも、System.out.println
コンストラクターには1回だけ実行されるがあり、その意味では1回だけインスタンス化されているように見えます。
シングルトンBeanは次のように構成されています。
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Singleton
@LocalBean
public class DummyDataRepository {
public DummyDataRepository() {
// Initial dummy data created here.
}
public final synchronized Foo findFooById(int id) {
// Retreive a Foo by ID.
// ...
}
public final synchronized void addFoo(Foo foo) {
// Add the Foo.
// ...
}
public final synchronized void updateFoo(Foo foo) {
// Find the existing Foo by foo.id and replace it with foo.
// ...
}
public final synchronized void deleteFoo(int id) {
// Find the existing Foo by id and delete it.
// ...
}
}
BeanがEJBコンテナの内外で異なる結果を生成する必要がある理由はないようです。外部リソースを使用しません。同期はBeanで管理されます(その点で同じである必要があります)。Beanはシングルトンとして宣言されます。しかし、コンテナでは、ステートレスセッションBeanとして機能しているように見えます。
GlassFish3.1.2.2を使用しています。
更新:
Beanをからに変更@javax.ejb.Singleton
し(そして、代わりにを@javax.enterprise.context.ApplicationScoped
介して必要な場所に注入し)、期待どおりに機能するようになりました。しかし、2つの間に違いはないはずです。シングルトンEJBは1回だけインスタンス化されますが、メソッド呼び出しの間に何らかの形でその状態を元に戻します。@javax.inject.Inject
@javax.ejb.EJB