Do czego służy odwołanie do zasobu w pliku web.xml?

Zastanawiam się tylko, kiedy / dlaczego zdefiniowałbyś <resource-ref>element w swoimweb.xml pliku?

Pomyślałbym, że zostałby zdefiniowany na serwerze sieci Web / aplikacji za pomocą JNDI, a następnie poszukać odniesienia JNDI w kodzie Java?

Definicja odniesienia do zasobu wydaje mi się nieco zbędna i nie mogę wymyślić, kiedy może być przydatna. Przykład:

<resource-ref>
  <description>Primary database</description>
  <res-ref-name>jdbc/primaryDB</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>CONTAINER</res-auth>
</resource-ref>

Zawsze możesz odwoływać się do zasobów w aplikacji bezpośrednio, używając ich nazwy JNDI skonfigurowanej w kontenerze, ale jeśli to zrobisz, zasadniczo połączysz nazwę kontenera z kodem. Ma to pewne wady, na przykład jeśli z jakiegoś powodu zechcesz później zmienić nazwę, musisz zaktualizować wszystkie odwołania we wszystkich aplikacjach, a następnie ponownie je skompilować i wdrożyć.

<resource-ref>wprowadza kolejną warstwę pośrednią: określasz nazwę, której chcesz użyć w pliku web.xml i, w zależności od kontenera, udostępniasz powiązanie w pliku konfiguracyjnym specyficznym dla kontenera .

Więc oto co się dzieje : powiedzmy, że chcesz odnośnika java:comp/env/jdbc/primaryDBnazwę. Kontener znajdzie, że web.xml zawiera <resource-ref>element dla jdbc/primaryDB, więc zajrzy do konfiguracji specyficznej dla kontenera, która zawiera coś podobnego do następującego:

<resource-ref>
  <res-ref-name>jdbc/primaryDB</res-ref-name>
  <jndi-name>jdbc/PrimaryDBInTheContainer</jndi-name>
</resource-ref>

Na koniec zwraca obiekt zarejestrowany pod nazwą jdbc/PrimaryDBInTheContainer .

Pomysł polega na tym, że określenie zasobów w pliku web.xml ma tę zaletę, że oddziela rolę programisty od roli wdrażającego . Innymi słowy, jako programista, nie musisz wiedzieć, jakie zasoby są faktycznie wywoływane w produkcji, a jako osoba wdrażająca aplikację będziesz mieć niezłą listę nazw do odwzorowania na rzeczywiste zasoby.