Vous pouvez toujours faire référence aux ressources de votre application directement par leur nom JNDI tel que configuré dans le conteneur, mais si vous le faites, vous câblez essentiellement le nom spécifique au conteneur dans votre code. Cela présente certains inconvénients, par exemple, si vous souhaitez changer le nom plus tard pour une raison quelconque, vous devrez mettre à jour toutes les références dans toutes vos applications, puis les reconstruire et les redéployer.
<resource-ref>introduit une autre couche d'indirection: vous spécifiez le nom que vous souhaitez utiliser dans le fichier web.xml et, en fonction du conteneur, vous fournissez une liaison dans un fichier de configuration spécifique au conteneur .
Alors, voici ce qui se passe : disons que vous voulez rechercher le java:comp/env/jdbc/primaryDBnom. Le conteneur trouve que web.xml a un <resource-ref>élément pour jdbc/primaryDB, donc il examinera la configuration spécifique au conteneur, qui contient quelque chose de similaire à ce qui suit:
<resource-ref>
<res-ref-name>jdbc/primaryDB</res-ref-name>
<jndi-name>jdbc/PrimaryDBInTheContainer</jndi-name>
</resource-ref>
Enfin, il renvoie l'objet enregistré sous le nom de jdbc/PrimaryDBInTheContainer.
L'idée est que la spécification des ressources dans le fichier web.xml a l'avantage de séparer le rôle de développeur du rôle de déployeur . En d'autres termes, en tant que développeur, vous n'avez pas besoin de savoir comment vos ressources requises sont réellement appelées en production, et en tant que responsable du déploiement de l'application, vous aurez une belle liste de noms à mapper sur de vraies ressources.