web.xml 中的resource-ref 有何用途？
我只是想知道何时/为什么要在 web.xml 文件中定义
我本以为它会使用 JNDI 在您的 Web/应用程序服务器中定义，然后在您的 Java 代码中查找 JNDI 引用？
资源引用定义对我来说似乎有点多余，我想不出它什么时候有用。例子：
<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>
I'm just wondering when/why you would define a <resource-ref> element in your web.xml file?
I would have thought that it would be defined in your web/app server using JNDI and then look up the JNDI reference in your Java code?
The resource-ref definition seems a bit redundant to me and I can't think of when it might be useful. Example:
<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>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您始终可以通过容器中配置的 JNDI 名称直接引用应用程序中的资源，但如果这样做，本质上就是将容器特定的名称连接到代码中。这有一些缺点，例如，如果您以后出于某种原因想要更改名称，则需要更新所有应用程序中的所有引用，然后重建并重新部署它们。
那么发生的情况：假设您要查找
java:comp/env/jdbc/primaryDB名称。容器发现 web.xml 有一个jdbc/primaryDB，因此它将查找容器 -具体配置，包含类似以下内容：最后，它返回以
jdbc/PrimaryDBInTheContainer名称注册的对象。想法是，在web.xml中指定资源具有将开发人员角色与部署者分离的优点角色。换句话说，作为开发人员，您不必知道所需资源在生产中实际被称为什么，并且作为部署应用程序的人员，您将有一个很好的名称列表来映射到实际资源。
You can always refer to resources in your application directly by their JNDI name as configured in the container, but if you do so, essentially you are wiring the container-specific name into your code. This has some disadvantages, for example, if you'll ever want to change the name later for some reason, you'll need to update all the references in all your applications, and then rebuild and redeploy them.
<resource-ref>introduces another layer of indirection: you specify the name you want to use in the web.xml, and, depending on the container, provide a binding in a container-specific configuration file.So here's what happens: let's say you want to lookup the
java:comp/env/jdbc/primaryDBname. The container finds that web.xml has a<resource-ref>element forjdbc/primaryDB, so it will look into the container-specific configuration, that contains something similar to the following:Finally, it returns the object registered under the name of
jdbc/PrimaryDBInTheContainer.The idea is that specifying resources in the web.xml has the advantage of separating the developer role from the deployer role. In other words, as a developer, you don't have to know what your required resources are actually called in production, and as the guy deploying the application, you will have a nice list of names to map to real resources.
这是一个老问题，但我有一个很好的例子来说明它的用处。我有两个基于通用框架的 WAR 文件，需要将它们部署到同一个应用程序服务器中...它们需要不同的数据源，但由于通用框架，它们使用相同的 JNDI 来查找。由于它们部署在 WebLogic 上进行生产，部署在 Tomcat 上进行测试，因此情况变得更加复杂，因此容器特定名称的可移植性是一个因素。
使用
web.xml，它查找jdbc/myDataSource的特定名称code>，并且在应用程序本身的外部，WebLogic 和 Tomcat 都可以配置为在该别名下提供合适的数据源。而且由于别名是特定于应用程序的，因此同一服务器中的多个应用程序可以请求相同的 JNDI 名称，并根据需要获取不同的数据源。An old question, but I have a nice example of where this is useful. I've got two WAR files based on a common framework, and which need to be deployed into the same application server... they require different data sources, but because of the common framework, they use the same JNDI to look it up. It's further complicated by the fact that they're deployed on WebLogic for production and Tomcat for testing, so portability of the container-specific names is a factor.
Using
<resource-ref>makes it simple... the framework supplies a commonweb.xmlwhich looks for a specific name ofjdbc/myDataSource, and external to the application itself, both WebLogic and Tomcat can be configured to serve a suitable data source under that alias. And because the alias is application specific, multiple applications in the same server can request the same JNDI name, and get different data sources as required.