Você sempre pode se referir aos recursos em seu aplicativo diretamente por seu nome JNDI, conforme configurado no contêiner, mas se fizer isso, essencialmente, você estará conectando o nome específico do contêiner em seu código. Isso tem algumas desvantagens, por exemplo, se você quiser alterar o nome posteriormente por algum motivo, precisará atualizar todas as referências em todos os seus aplicativos e, em seguida, reconstruí-los e reimplementá-los.
<resource-ref>
introduz outra camada de indireção: você especifica o nome que deseja usar no web.xml e, dependendo do contêiner, fornece uma ligação em um arquivo de configuração específico do contêiner .
Então aqui está o que acontece : digamos que você queira pesquisar o java:comp/env/jdbc/primaryDB
nome. O contêiner descobre que web.xml tem um <resource-ref>
elemento para jdbc/primaryDB
, então ele examinará a configuração específica do contêiner, que contém algo semelhante ao seguinte:
<resource-ref>
<res-ref-name>jdbc/primaryDB</res-ref-name>
<jndi-name>jdbc/PrimaryDBInTheContainer</jndi-name>
</resource-ref>
Finalmente, ele retorna o objeto registrado com o nome de jdbc/PrimaryDBInTheContainer
.
A ideia é que especificar recursos no web.xml tem a vantagem de separar a função de desenvolvedor da função de implantador . Em outras palavras, como desenvolvedor, você não precisa saber como seus recursos necessários são realmente chamados na produção e, como o cara que implementa o aplicativo, você terá uma boa lista de nomes para mapear para recursos reais.