Présentation de la nouvelle fonctionnalité Servlet3.0:
En tant que membre du système de spécification Java EE 6, Servlet 3.0 a été publié avec la spécification Java EE 6. Cette version fournit plusieurs nouvelles fonctionnalités basées sur la version précédente (Servlet 2.5) pour simplifier le développement et le déploiement d'applications Web. L'introduction de plusieurs de ces fonctionnalités a rendu les développeurs très excités et a également reçu des éloges de la communauté Java:
- Prise en charge du traitement asynchrone: avec cette fonctionnalité, le thread Servlet n'a plus besoin de bloquer tout le temps, puis la réponse ne peut pas être émise tant que le traitement métier n'est pas terminé, et enfin le thread Servlet est terminé. Après avoir reçu la demande, le thread Servlet peut déléguer l'opération fastidieuse à un autre thread pour terminer, et revenir au conteneur sans générer de réponse. Compte tenu du temps nécessaire au traitement de l'entreprise, cela réduira considérablement l'occupation des ressources du serveur et augmentera la vitesse du traitement simultané.
- Nouvelle prise en charge des annotations: cette version ajoute plusieurs annotations pour simplifier la déclaration de servlet, filtre et écouteur, ce qui rend le fichier de description de déploiement web.xml n'est plus nécessaire à partir de cette version. Oui
- Prise en charge de la pluggabilité: les développeurs familiers avec Struts2 se souviendront certainement des fonctionnalités d'intégration de divers frameworks communs, y compris les plugins Spring through. Les plug-ins correspondants sont regroupés dans des packages JAR et placés sur le chemin d'accès aux classes, et Struts2 peut automatiquement charger ces plug-ins pendant l'exécution. Servlet 3.0 propose désormais des fonctionnalités similaires. Les développeurs peuvent facilement étendre les fonctionnalités des applications Web existantes via des plug-ins sans modifier les applications d'origine.
Note: A propos Servlet3.0 aujourd'hui démontrent les nouvelles fonctionnalités se concentrent sur le fichier de configuration modulaire web-fragment.xml (l'expérience réelle du projet) , sur les autres nouvelles fonctionnalités peuvent se référer à cet article: Servlet3.0 nouvelles fonctionnalités détaillées ou Bo Amis de l'article
1. Quelle est la différence entre web-fragment.xml et web.xml?
Le modèle de fichier web.xml commun est:
<? xml version = "1.0" encoding = "UTF-8" ?> < web-app xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns = "http://xmlns.jcp .org / xml / ns / javaee " xsi: schemaLocation =" http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd " version =" 3.1 " > ................ </ web-app >
Le modèle de fichier web-fragment.xml est:
<? xml version = "1.0" encoding = "UTF-8" ?> < web-fragment id = "WebFragment_ID" version = "3.0" xmlns = "http://java.sun.com/xml/ns/javaee" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml /ns/javaee/web-fragment_3_0.xsd " > ............ </ web-fragment >
La première est que la balise racine n'est pas la même. La balise de fichier web.xml normale est <web-app> </ web-app> Ceci représente le fichier de configuration principal du projet Web Java, et la balise racine du fichier web-fragment.xml est <web-fragment > </ web-fragment>, et web-fragment.xml et web.xml, à l'exception de la référence XSD déclarée dans l'en-tête, la configuration principale est exactement la même que web.xml, Servlet 3.0 a introduit le " Le fichier de description de déploiement web-fragment.xml de "Fragment de descripteur de déploiement de module Web" doit être stocké dans le répertoire META-INF du fichier JAR. Le fichier de description de déploiement peut contenir tout ce qui peut être défini dans web.xml. Le package JAR est généralement placé dans le répertoire WEB-INF / lib. De plus, toutes les ressources utilisées par le module, y compris les fichiers de classe et les fichiers de configuration, doivent uniquement être chargées sur le chemin de la chaîne de chargement de classe du conteneur, telles que les classes Annuaire etc. On peut dire que cette nouvelle fonctionnalité est toujours très pratique. Vous n'avez pas besoin de mettre toutes les configurations gonflées dans le fichier web.xml. Vous pouvez configurer toutes les configurations initiales dans le fichier web-fragment.xml, comme dans un projet distribué. L'analyse des packages Spring aura des spécifications correspondantes dans certaines entreprises. Même les contrôleurs et les services nécessitent des noms de packages pour se conformer aux spécifications, afin que nous puissions extraire un projet et charger le fichier de configuration Spring uniformément sur le Web. -fragment.xml pour charger ces fichiers de configuration de ressort, de sorte que dans le travail des autres développeurs, vous n'avez pas besoin de configurer la configuration presque répétée du ressort à chaque fois, référez-vous directement au package jar correspondant pour terminer la configuration, ce qui peut améliorer l'efficacité .
Par exemple:
******************************************
De cette façon, après que d'autres développeurs se soient référés au projet, vous pouvez faire "0 configuration spring" pour utiliser la commodité apportée par spring.
2. L'ordre d'exécution de web.xml et web-fragment.xml?
* Tout d'abord: web.xml est définitivement le premier à être exécuté car web.xml est l'entrée du projet web
* L'ordre d'exécution de plusieurs web-fragement.xml peut être configuré. Exemples:
En utilisant l' élément <absolute-ordering> dans le descripteur de déploiement ( web.xml ) , vous pouvez définir l'ordre absolu comme suit:
<? xml version = "1.0" encoding = "UTF-8" ?> < web-app xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns = "http: //java.sun .com / xml / ns / javaee " xmlns: web =" http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd " xsi: schemaLocation =" http://java.sun.com / xml / ns / JavaEE http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd » id = "WebApp_ID" la version = "3.0" > < nom > MonApp </ nom > < absolute- commande > < nom > < nom > MyFragment2 </ nom > </ ordre absolu > ... </ web-app >
Ordre relatif des fragments Web:
En utilisant l' élément <ordering> dans web-fragment.xml , vous pouvez définir l'ordre relatif. Trois fichiers web-fragment.xml différents sont donnés ci-dessous, comme suit:
web-fragment.xml ：
< fragment Web > < nom > MonFragment1 </ nom > < commande > < après > < nom > MonFragment2 </ nom > </ après > </ commande > ... </ Web-fragment >
web-fragment.xml ：
< fragment Web > < nom > MonFragment2 </ nom > ... </ fragment Web >
web-fragment.xml ：
< web-fragment > < nom > MyFragment3 </ name > < commande > < avant > < autres /> </ avant > </ commande > .. </ web-fragment >
Le <before> indique que le fragment contenant doit être réservé avant le nom du fragment pour fournir des balises < name > imbriquées . <Après> balise doit spécifier imbriqué <name> balise fragments après les fragments sont classés sous le nom fourni . Le < avant > < autres /> </ avant > indique que le fragment contenant doit être le premier dans l'ordre après web.xml.
La séquence des fragments de page Web ci-dessus est la suivante:
- MyFragment3
- MyFragment2
- MyFragment1
Références de: Tri des fragments Web
3. Effet de démonstration réel?
* Créez d'abord un projet de test maven, voici uniquement le fichier web-fragment.xml, les autres ne sont pas seulement pour la démonstration:
Configurez le paramètre context-param dans le fichier web-fragment.xml:
Ensuite, installez-le dans l'entrepôt local
Remarque: Ce fichier doit être stocké dans le répertoire META-INF du fichier JAR et configuré dans maven:
< build > < resources > < resource > < directory > src / main / resources </ directory > < targetPath > META-INF / </ targetPath > </ resource > </ resources > </ build >
*****************
* Créez un projet AA javaweb, ajoutez un écouteur ou des paramètres de contexte:
Lancer l'impression des résultats du projet:
Les résultats montrent que les paramètres de la configuration web-fragment.xml dans le projet de test prennent effet, et seule l'application du package jar peut terminer la configuration modulaire du fichier web.xml.