Un bean est une classe Java avec des noms de méthode qui suivent les directives Java Bean (également appelées modèles de conception) pour les propriétés , les méthodes et événements. Ainsi, toute méthode publique de la classe de bean qui ne fait pas partie d'une définition de propriété est une méthode de bean. Au minimum, une classe Java même avec une propriété comme seul membre (bien sûr, accompagnant le getter et le setter requis), une méthode publique comme le seul membre ou juste une méthode d'enregistrement d'écouteur d'événement public est un bean Java. De plus, la propriété peut être soit une propriété en lecture seule (a une méthode getter mais pas de setter) ou une propriété en écriture seule (a une méthode setter uniquement). Le bean Java doit être une classe publique pour être visible par n'importe quel outil ou conteneur de beanbox. Le conteneur doit pouvoir l'instancier; ainsi, il doit également avoir un constructeur public. le spécification JavaBeansn'exige pas qu'un bean ait un constructeur public zéro-args, explicite ou par défaut, pour qu'un conteneur l'instancie. Si vous pouviez fournir un fichier (avec l'extension .ser) contenant une instance sérialisée, un outil beanbox pourrait utiliser ce fichier pour instancier un bean prototype. Sinon, le bean doit avoir un constructeur public à zéro argument, explicite ou par défaut.
Une fois le bean instancié, l'API Java Bean (java.beans. *) Peut l'introspecter et appeler des méthodes dessus. Si aucune classe implémentant l'interface BeanInfo ou étendant une implémentation BeanInfo, classe SimpleBeanInfo, n'est disponible, l'introspection implique l'utilisation de la réflexion (introspection implicite) pour étudier les méthodes prises en charge par un bean cible, puis appliquer des modèles de conception simples (les directives) à déduire de ces méthodes quelles propriétés, événements et méthodes publiques sont pris en charge. Si une classe implémentant l'interface BeanInfo (pour un bean Foo, il doit être nommé FooBeanInfo) est disponible, l'API contourne l'introspection implicite et utilise des méthodes publiques (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) de cette classe pour obtenir le information. Si une classe étendant SimpleBeanInfo est disponible, selon laquelle des méthodes publiques SimpleBeanInfo (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) sont remplacées, elle utilisera ces méthodes substituées pour obtenir des informations; pour une méthode qui n'est pas remplacée, elle sera par défaut l'introspection implicite correspondante. Un bean doit de toute façon être instancié même si aucune introspection implicite n'y est effectuée. Ainsi, l'exigence d'un constructeur zeri-args public. Mais, bien sûr, l'interface Serializable ou Externalizable n'est pas nécessaire pour qu'elle soit reconnue. Cependant, la spécification Java Bean dit: «Nous aimerions également que ce soit« trivial »pour le cas commun d'un petit Bean qui veut simplement que son état interne soit sauvegardé et ne veut pas y penser. Ainsi, tous les beans doivent implémenter une interface sérialisable ou extensible. Global, La spécification JavaBeans n'est pas difficile et rapide sur ce qui constitue un bean. "L'écriture de composants JavaBeans est étonnamment simple. Vous n'avez pas besoin d'un outil spécial et vous n'avez pas besoin d'implémenter d'interfaces. L'écriture de beans consiste simplement à suivre certaines conventions de codage. Tout ce que vous avez à faire est de faire ressembler votre classe un bean - les outils qui utilisent des beans pourront reconnaître et utiliser votre bean. " Trivialement, même la classe suivante est un Java Bean,
public class Trivial implements java.io.Serializable {}
Disons qu'un constructeur de bean a des paramètres. Supposons que certains sont des types simples. Le conteneur peut ne pas savoir quelles valeurs leur affecter; même si c'est le cas, l'instance résultante pourrait ne pas être réutilisable. Cela n'a de sens que si l'utilisateur peut configurer (spécifier des valeurs) par exemple des annotations ou des fichiers de configuration xml comme dans les beans Spring. Et supposons que certains paramètres soient des types de classe ou d'interface. Encore une fois, le conteneur peut ne pas savoir quelles valeurs lui affecter. Cela n'a de sens que si l'utilisateur peut configurer (spécifier des objets spécifiques) par exemple des annotations ou des fichiers de configuration xml. Cependant, même dans Spring (via les fichiers de configuration xml), l'attribution d'objets spécifiques (avec des noms de chaîne) aux arguments du constructeur (attribut ou élément des arguments du constructeur) n'est pas sécurisée de type; c'est essentiellement comme l'injection de ressources. Faire des références à d'autres beans Spring (appelés collaborateurs; via un élément dans un élément d'argument constructeur) est essentiellement une injection de dépendance et donc sûr pour les types. De toute évidence, une dépendance (bean collaborateur) peut avoir un constructeur avec des paramètres injectés; ces dépendances injectées peuvent avoir un constructeur avec des paramètres et ainsi de suite. Dans ce scénario, en fin de compte, vous auriez besoin de certaines classes de bean (par exemple, MyBean.class) que le conteneur peut instancier en appelant simplement new MyBean () avant de pouvoir construire les autres beans collaboratifs via l'injection de dépendances sur les constructeurs - ainsi, l'exigence de les beans pour avoir un constructeur public à zéro args. Supposons que si un conteneur ne prend pas en charge l'injection de dépendances et / ou n'autorise pas l'attribution de valeurs de type simple au constructeur via des annotations ou des fichiers de configuration xml comme dans Spring, Les constructeurs de bean ne doivent pas avoir de paramètres. Même une application Spring beans aurait besoin de certains beans pour avoir un constructeur public sans arguments (par exemple, dans un scénario où votre application Spring n'a pas de bean avec juste des types simples comme arguments de constructeur).
Les beans gérés JSF s'exécutent dans un conteneur Web. Ils peuvent être configurés avec l'annotation @ManagedBean ou avec un fichier de ressources de configuration d'application managed-bean.xml. Cependant, il prend en charge l'injection via l'injection de ressources (non sécurisée) uniquement; ne convient pas à l'injection sur les constructeurs. le spécification JSFrequiert que les beans gérés doivent avoir un constructeur public à zéro argument. De plus, il indique: «À partir de la version 2.3 de cette spécification, l'utilisation de la fonction de bean géré comme spécifié dans cette section est fortement déconseillée. Une solution meilleure et intégrée de manière plus cohérente pour résoudre le même problème consiste à utiliser Contexts and Dependency Injection (CDI), comme spécifié dans JSR-365. "En d'autres termes, les beans gérés CDI à utiliser, qui offrent une injection de dépendance de typesafe sur les constructeurs similaires aux Spring beans. La spécification CDI adopte la spécification Managed Beans, qui s'applique à tous les conteneurs de la plate-forme JEE, pas seulement au niveau Web. Ainsi, le conteneur Web doit implémenter la spécification CDI.
Voici un extrait du spécification du bean géré
«Les beans gérés sont des objets gérés par conteneur avec des exigences minimales, autrement connus sous l'acronyme« POJO »(Plain Old Java Objects)… ils peuvent être vus comme une version améliorée de la plate-forme Java EE du modèle de composant JavaBeans trouvé sur la plate-forme Java SE …. Le lecteur ne manquera pas que les beans gérés ont un précurseur dans l'installation homonyme trouvée dans la technologie JavaServer Faces (JSF)… Les beans gérés tels que définis dans cette spécification représentent une généralisation de ceux trouvés dans JSF; en particulier, les beans gérés peuvent être utilisés n'importe où dans une application Java EE, pas seulement dans les modules Web. Par exemple, dans le modèle de composant de base, les beans gérés doivent fournir un constructeur sans argument, mais une spécification qui s'appuie sur les beans gérés, comme CDI (JSR-299), peut assouplir cette exigence et permettre aux beans gérés de fournir aux constructeurs des signatures plus complexes, à condition qu'ils suivent des règles bien définies ... Un bean géré ne doit pas être: une classe finale, une classe abstraite, une classe interne non statique . Un bean géré peut ne pas être sérialisable contrairement à un composant JavaBean standard. » Ainsi, la spécification des beans gérés, autrement appelés POJO ou POJO, permet une extension comme dans CDI.
La spécification CDI redéfinit les beans gérés comme: Lors de l'exécution dans Java EE, une classe Java de niveau supérieur est un bean géré si elle répond aux exigences:
• Ce n'est pas une classe intérieure. • Il s'agit d'une classe non abstraite ou est annotée @Decorator. • Il n'implémente pas javax.enterprise.inject.spi.Extension. • Il n'est pas annoté @Vetoed ou dans un package annoté @Vetoed. • Elle a un constructeur approprié, soit: la classe a un constructeur sans paramètres, soit la classe déclare un constructeur annoté @Inject.
Toutes les classes Java qui remplissent ces conditions sont des beans gérés et donc aucune déclaration spéciale n'est requise pour définir un bean géré. Ou
s'il est défini comme étant un bean géré par toute autre spécification Java EE et si
• Il n'est pas annoté avec une annotation de définition de composant EJB ou déclaré en tant que classe de bean EJB dans ejb-jar.xml.
Contrairement aux beans Spring, il ne prend pas en charge les constructeurs avec des types simples, ce qui pourrait être possible s'il prend en charge la configuration avec des fichiers de configuration xml comme dans Spring ou toute autre annotation.
Les EJB s'exécutent dans un conteneur EJB. Ses spécificationdit: "Un composant de bean session est un bean géré." "La classe doit avoir un constructeur public qui ne prend aucun argument", dit-elle pour le bean session et le bean géré par message. De plus, il dit: "La classe bean session est pas nécessaire pour implémenter l'interface SessionBean ou l'interface Serializable. " Pour la même raison que les beans JSF, l'injection de dépendances EJB3 étant essentiellement une injection de ressources, les beans JSF ne prennent pas en charge les constructeurs avec des arguments, c'est-à-dire via l'injection de dépendances. Cependant, si le conteneur EJB implémente CDI, «Facultativement: la classe peut avoir un constructeur supplémentaire annoté avec l'annotation Inject ", indique-t-il pour le bean session et le bean géré par message car," Un EJB empaqueté dans une archive de bean CDI et non annoté avec javax.enterprise.inject.Vetoed annotation, est considéré comme un CDI-enabled haricot."