Quelle est la différence entre @ApplicationScoped et @Singleton étendues en CDI?

En CDI il y a le @ApplicationScoped et l' (javax.inject) @Singleton pseudo-portée. Quelle est la différence entre eux? Outre le fait que @ApplicationScoped est mandaté, et @Singleton ne l'est pas.

Pouvez je viens de changer mon @Singleton de la fève à la @ApplicationScoped? Peut @ApplicationScoped bean avoir deux (ou plus) des cas?

  • Avez-vous lu le Soudure de référence? Il y a quelques explications sur les différences pratiques entre @ApplicationScoped et @Singleton à sa section 5.4 (p. 36).
  • Je trouve aussi le sommaire des différences à la fin de cet article germanescobar.net/2010/04/... utile
  • qui Singleton portée êtes-vous allusion - javax.ejb ou javax.injecter?
InformationsquelleAutor amorfis | 2010-12-29
  1. 24

    @Singleton ne fait pas partie de la spécification CDI. Il fait partie de l'EJB et javax.inject (JSR 330). Il n'est pas mentionné dans la spec, quel est son comportement, de sorte que vous ne pouvez compter que sur ce qui est écrit dans la Soudure de la documentation.

    • Ce n'est pas vrai. Il est l'annotation javax.injecter.Singleton. Il est le cadre de CDI. Vérifiez ici: docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/...
    • J'ai le CDI spec en face de moi. J'ai même mis en place des parties de lui, et il ne mentionne rien au sujet @Singleton. Il est montré que dans un seul exemple, sans précisions. Il est vrai que la CDI s'appuie sur javax.inject, mais strictement parlant, il ne fait pas partie de la CDI spec. Cela dit, j'ai corrigé ma réponse un peu.
    InformationsquelleAutor Bozho
  2. 16

    en bref: Vous pouvez même mélanger (@Singleton et @ApplicationScoped) et il fait sens dans certains scénarios.
    (et fonctionne comme prévu dans la mienne!)

    En outre d'autres réponses jusqu'à présent, j'aimerais ajouter quelques points de plus pour clarifier dans des scénarios du monde réel.

    Pour moi, cette question s'est développé à partir de Comment puis-je la force d'une application étendue de la fève à instancier au démarrage de l'application?
    Dans la discussion j'ai affirmé cela et ne peut pas trouver un argument valable contre elle jusqu'à présent:

    Dans beaucoup de scénarios réels/setups, je dirais que c'est dur à
    certainement dire - abstrait/modélisation point de vue - si
    quelque chose est (ou va devenir/être traités comme) un EJB ou une application étendue du managed bean.

    (discutable, mais non exhaustive) des arguments (de mon point de vue) à l'encontre de ce jour:
    (@BalusC et tous les autres: j'aimerais bien les voir en étant concluante, mais si pas, le ci-dessus peut également être vrai et pourtant les arguments peuvent encore aider le lecteur à obtenir les différences/avantages/inconvénients/bonnes/mauvaises pratiques)

    EJB vs Managed Bean

    BalusC: C'est un EJB pas un managed bean, ce qui est très différent. Les ejb exécuter en arrière-plan et géré les haricots en frontend. Les ejb exécuter dans les transactions contexte.
    [...] Vous avez juste confondu les haricots d'entreprise avec la gestion des haricots et je viens de remarquer que.

    mais:

    moi: je pense que vous n'êtes pas tout à fait correct et à surestimer la signification d'utilisation et il semble discutable pour moi. http://en.wikipedia.org/wiki/Enterprise_JavaBeans

    Enterprise JavaBeans (EJB) est un gérés, logiciel de serveur modulaire pour la construction de logiciels d'entreprise, et l'un de plusieurs Api Java. EJB est un logiciel côté serveur composant qui encapsule la logique métier d'une application.

    Types de Haricots d'Entreprise

    Beans de Session [3] qui peut être soit "Dynamique", "Apatrides" ou "Singleton" [...]

    Message Driven Beans [...]

    ... ce qui reste vrai dans mon cas.

    EJB Singleton vs Application Étendue de Haricot

    Verrouillage

    BalusC: Un EJB singleton n'est pas la même chose qu'une application étendue de haricot. Un EJB singleton est en lecture/écriture verrouillé et donc potentiellement inefficace/overconvoluted pour la tâche que vous aviez en tête. Longue histoire courte: Prenez un bon Java EE livre et d'apprendre à utiliser le bon outil pour le travail. D'une manière n'est certainement pas dans l'autre sens. Qu'il fonctionne ne veut pas dire que c'est le bon outil. Une masse est capable de fixation d'une vis, mais ce n'est pas forcément le bon outil pour ça 🙂

    mais:

    (Je ne peux pas voir la masse ici - désolé ...)
    Il est bon de savoir le verrouillage par défaut (je n'était pas au courant de celui-ci), mais cela semble être incorrecte de nouveau: Oracle Java EE 6 Tutoriel dans la Gestion de l'Accès Simultané à un Singleton Bean de Session

    Lors de la création d'un singleton bean de session, l'accès simultané à l'singleton méthodes d'affaires peut être contrôlé de deux manières: container-managed simultanéité et bean géré par la simultanéité.
    [...]

    Bien que par défaut, les singletons utilisation container-managed simultanéité, l' @ConcurrencyManagement(CONTENEUR) annotation peut être ajouté au niveau de la classe du singleton de définir explicitement la gestion de la concurrence de type

    InformationsquelleAutor Andreas Dietrich
  3. 9

    Habituellement, lorsque vous voulez avoir une seule instance d'un objet, vous devriez probablement utiliser @ApplicationScoped annotation - tel objet est mandaté et peut donc même être correctement sérialisé out-of-the-box.

    D'autre part, il y a aussi de nombreux cas, où vous voulez une seule instance de la classe, mais cette classe ne peut pas être mandaté (par exemple, en raison de finale) - puis @Singleton est une opération de sauvetage. Parce que Singleton est un pseudo-champ d'application et n'est pas mandaté comme tout "normal" de la portée.

    InformationsquelleAutor G. Demecki
  4. 9

    @Singleton dans la JSR-299 fait référence à Singleton beans de session (javax.ejb.Singleton, pas javax.inject.Singleton), pas de la JSR-299 géré les haricots dans un champ appelé Singleton.

    Que vous pourriez trouver dans votre serveur @ApplicationScoped est l'un par l'OREILLE ou par la GUERRE/EJB-JAR comme il n'est pas clair dans le cahier des charges, mais vous devriez certainement pas s'attendre à un par la JVM.

    InformationsquelleAutor covener
  5. 4

    Il y a une différence:
    @Singleton n'est pas du haricot de la définition des annotations, comme le Singleton portée n'est pas une portée normale.
    Puis @ApplicationScoped est bean définition des annotations.

    Avec le CDI 1.1 spec: Lors de l'application de la découverte-mode = annoté, la Soudure ne permet pas d'identifier les haricots avec @Singleton et pas chargé de cette

    InformationsquelleAutor vigor
  6. 2

    L'une des principales différences que vous pouvez écrire votre classe par défaut de l'entrepreneur privé de modificateur d'accès lors de l'utilisation de javax.inject.Singleton, mais la classe par défaut de l'entrepreneur avec au moins par défaut modificateur d'accès lors de l'utilisation de javax.enterprise.context.ApplicationScoped et c'est JBOSS 6.1 GA Final mise en œuvre

    • Vouliez-vous dire “constructeur par défaut”?
    InformationsquelleAutor user1017344