Java Spring Multiple ApplicationContext
La définition du ressort ApplicationContext est très ambiguë, j'ai presque fini tout un livre de tutoriel mais je ne comprends toujours pas ce que représente le ApplicationContext.
Selon l'API Spring, ApplicationContext est:
Interface centrale pour fournir la configuration d'une application. Ceci est en lecture seule pendant l'exécution de l'application, mais peut être rechargé si l'implémentation le prend en charge.
L'interface racine pour accéder à un conteneur de beans Spring. Il s'agit de la vue client de base d'un conteneur de beans.
D'en haut, mes questions sont:
1) Je continue de voir le livre mentionné "conteneur", à quoi le conteneur fait-il référence? Un conteneur signifie-t-il un Java? Ou un conteneur fait référence à un objet ApplicationContext?
2) Si j'instancie deux ApplicationContext dans une seule Java (les deux dans le corps main), ces deux interfaces sont-elles reliées à un conteneur central? Ou deux instances distinctes ? Voir le code ci-dessous, quelle est la différence entre context1 et context2? S'il y a un Singleton dans Beans.xml, il est invoqué par context1 et context2, s'agit-il de deux instances séparées ou de la même instance?
ApplicationContext context1 = new ClassPathXmlApplicationContext("Beans.xml");
ApplicationContext context2 = new ClassPathXmlApplicationContext("Beans.xml");
Par conteneur, ils se réfèrent au ressort central Inversion du conteneur de contrôle . Le conteneur fournit un moyen d'initialiser/amorcer votre application (chargement de la configuration dans des fichiers xml ou des annotations), en utilisant réflexion , et pour gérer le cycle de vie de Java objets, appelés beans ou objets gérés .
Au cours de cette phase initiale, vous n'avez pas (normalement, mais c'est possible) de contrôle dans votre application, au lieu de cela, vous obtiendrez un état complètement initialisé pour l'application lorsque le démarrage est terminé (ou rien, en cas d'échec).
Il s'agit d'un remplacement, ou éventuellement d'un ajout, à ce qu'on appelle un conteneur EJB3 ; pourtant, le ressort pourvu que l'on n'adhère pas à la norme définie par l'EJB. Historiquement, l'adoption d'EJB a été limitée par la complexité de cette spécification, Spring étant un projet nouvellement créé pour avoir des fonctionnalités comparables EJB3 fonctionnant sur un jvm J2SE et sans conteneur EJB, et avec une configuration beaucoup plus facile.
ApplicationContext (en tant que interface , et par les saveurs d'implémentation directes) est le moyen d'implémenter ce conteneur IoC, par opposition au BeanFactory, qui est maintenant (un peu utilisé et) façon plus directe de gestion des beans, qui fournit d'ailleurs les fonctionnalités de base de mise en œuvre pour ApplicationContext.
Selon votre deuxième question, vous pouvez avoir plusieurs instances d'ApplicationContexts, dans ce cas, elles seront complètement isolées, chacune avec sa propre configuration.
D'abord vous questions:
1) Je continue de voir le livre mentionné "conteneur", à quoi le conteneur fait-il référence? Un conteneur signifie-t-il un Java? Ou un conteneur fait référence à un objet ApplicationContext?
ApplicationContext est l'interface centrale, mais le conteneur sous-jacent est un BeanFactory. Plus précisément, BeanFactory est une interface de niveau inférieur implémentée par tous les contextes d'application à partir desquels vous obtenez les Beans. En ce sens, je pense que le conteneur Word représente ici le BeanFactory - un par ApplicationContext.
2) Si j'instancie deux ApplicationContext en une seule Java (un corps principal), ces deux interfaces sont-elles reliées à un conteneur central? Ou deux instances distinctes différentes? Voir le code ci-dessous, quelle est la différence entre context1 et context2? S'il existe un singleton dans Beans.xml, il est invoqué par context1 et context2, s'agit-il de deux instances séparées ou de la même instance?
ApplicationContext context1 = new ClassPathXmlApplicationContext ("Beans.xml"); ApplicationContext context2 = new ClassPathXmlApplicationContext ("Beans.xml");>
Avec ces instanciations, vous obtiendrez 2 contextes d'application totalement indépendants. Un haricot déclaré en premier ne sera pas trouvé dans l'autre.
MAIS
Il est courant d'avoir plus d'un contexte d'application dans une application Web, car Spring a une notion de hiérarchies d'ApplicationContext. Vous pouvez les déclarer comme:
ApplicationContext context1 = new ClassPathXmlApplicationContext("Beans.xml");
ApplicationContext context2 = new ClassPathXmlApplicationContext("Beans.xml", context1);>
Ici, vous pouvez récupérer à partir de context1 uniquement des beans déclarés, mais à partir de context2 vous récupérerez les beans de context2etcontext1. Plus précisément, les haricots sont d'abord recherchés dans context2 et s'il n'est pas trouvé alors recherché dans context1.
Ceci est utilisé dans Spring MVC où vous avez normalement un contexte racine (pour tous les beans non directement liés au MVC DispatcherServlet) et un contexte enfant dédié au DispatcherServlet qui contiendra les beans pour les contrôleurs , vues, intercepteurs, etc.
Je continue de voir le livre mentionné "conteneur", à quoi le conteneur fait-il référence? Un conteneur signifie-t-il un Java? Ou un conteneur fait référence à un objet ApplicationContext?
Ici conteneur signifie conteneur à ressort qui n'est rien d'autre que ApplicationContext. Cela lit en interne la configuration du ressort et charge les classes en fonction de la configuration. Vous pouvez le penser comme SpringProcessor qui fournit les diverses fonctionnalités telles que l'initialisation du bean, l'injection, i18n, le post-traitement du bean, etc.
avec
ApplicationContext context1 = new ClassPathXmlApplicationContext ("Beans.xml"); ApplicationContext context2 = new ClassPathXmlApplicationContext ("Beans.xml");
Il y aura deux conatiners, donc deux fèves singleton. Ici singleton signifie instance singleton par conteneur. Idéalement, vous ne devriez avoir qu'un seul récipient jusqu'à ce que vous en ayez une raison. À des fins d'apprentissage, il est logique de comprendre les concepts
ApplicationContext est une implémentation d'un conteneur Spring. En termes simples, le conteneur Spring gère l'ensemble de l'application Spring via un ApplicationContext. Le conteneur Spring via ApplicationContext gère le cycle de vie d'un bean Spring i; e, de l'initiation à la destruction.
Un conteneur à ressort est imbriqué dans un conteneur J2EE.
Je continue de voir le livre mentionné "conteneur", à quoi le conteneur fait-il référence? Un conteneur signifie-t-il un Java? Ou un conteneur fait référence à un objet ApplicationContext?
Un conteneur gère le cycle de vie d'un objet. Tomcat est un exemple de conteneur. Tout comme le conteneur Spring gère l'application via ApplicationContext, un conteneur J2EE Tomcat gère l'application via web.xml
Un conteneur fournit un support de communication. Sécurité dans une application web. Prise en charge JSP, internationalisation, propagation d'événements et de nombreuses autres fonctionnalités. Il prend en charge le multithreading, génère un nouveau thread pour chaque demande de ressource. Vous n'avez pas besoin d'écrire explicitement le code pour cela. Tout comme un conteneur à ressort, un conteneur J2ee gère un cycle de vie de servlet.
Si j'instancie deux ApplicationContext en une seule Java (un corps principal), ces deux interfaces sont-elles reliées à un conteneur central?
Si vous souhaitez instancier plusieurs ApplicationContexts dans votre application. Ce sera dans une hiérarchie enfant parent. Il y aura un ApplicationContext racine et puis il y aura un ApplicationContext enfant respectif pour chaque DispatcherServlet. Les beans globaux à l'application seront définis dans le ApplicationContext racine. Tous les ApplicationContexts seront gérés par un seul conteneur à ressort.
1) le conteneur est un objet Java, une instance d'une des implémentations ApplicationContext comme ClassPathXmlApplicationContext.
2) Il s'agit de 2 conteneurs différents, si Beans.xml a un bean singleton B1, alors context1.getBean ("B1") et context2.getBean ("B1") renverra 2 instances différentes de B1
Vous avez ajouté une balise "Java-ee". Spring est souvent utilisé dans les applications Web exécutées sur un serveur d'applications. En règle générale, chaque application Web possède sa propre application. Les applications Web sont séparées et c'est probablement ce qui est appelé conteneur dans la documentation car vous ne pouvez pas partager régulièrement des variables avec différentes applications/conteneurs.
Vous pouvez avoir deux contextes dans une application. Si vous avez deux contextes, chacun aura son propre singleton.