为什么要将 hibernate SessionFactory 绑定到 JNDI 资源？
在我当前学习 hibernate 并将其设置为使用应用程序服务器的连接池的冒险中，大多数示例和资源都指出了在此过程中将 SessionFactory 绑定到应用程序服务器中的 JNDI 资源的方向。
我想知道这样做有什么好处？因为您可以访问连接池而不需要这样做。
In my current adventure of learning hibernate and setting it up to use an appserver's connection pool, most examples and resources out there point you in the direction of binding the SessionFactory to a JNDI resource in your appserver in the process.
I wondering what the benefit of this is? Since the you can access a the connection pool with out doing this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想说，这与您使用 JNDI 执行任何操作的原因相同 - 将配置从应用程序移至部署环境中。
使用 JNDI，您基本上会说“此应用程序需要一个
SessionFactory；其名称应为 X”，只要应用程序服务器有一个名为 X 的SessionFactory，您就会感到高兴配置。这种外部化有几个吸引人的好处：您可以在不同的机器上使用截然不同的配置（生产和 QA 使用 Oracle，开发人员使用 HSQL，...）。
您不需要让您的构建过程了解配置（不再需要
ant war_for_qa或使用 Maven 配置文件）。您不会想将配置检查到版本控制中，因此您的实时数据库密码不会被每个曾经（或将有！）访问存储库的临时工、实习生、顾问或前员工知道.
您的安装/配置说明不会包含诸如“要配置数据库登录，编辑 WAR 文件中的文件 foo.properties”之类的项目，这将不可避免地导致配置在最糟糕的情况下在生产服务器上被覆盖，因为一个整个周末都在工作的系统管理员碰巧部署了一个未经编辑的 WAR，因为周日下午咖啡用完了。
JNDI 恰好是在 Java 中进行这种外部化的“标准”方式，这意味着新的开发人员/管理员不需要两天的培训来学习您自己的自制配置系统的怪癖，这确实非常聪明但是有一个没有人愿意深入研究的奇怪错误，因为它确实很奇怪，而且它有一个非常简单的解决方法，&c。
相关： JNDI 的目的是什么？
The same reason you'd use JNDI for anything, I'd say - moving the configuration out of the application, into the deployment environment.
With JNDI, you basically say "this application needs a
SessionFactory; and its name shall be X" and you're happy as long as the application server has aSessionFactorycalled X configured. This kind of externalization has several appealing benefits:You can use wildly different configurations on different machines (production and QA use Oracle, developers use HSQL, ...).
You don't need to make your build process aware of configurations (no more
ant war_for_qaor screwing around with Maven profiles).You're not tempted to check configurations into version control, and so your live database password won't be known to every temp, intern, consultant or ex-employee who's ever had (or will have!) access to the repository.
Your installation/configuration instructions won't include items like "to configure the database login, edit the file foo.properties in the WAR file" which will inevitably result in configurations being overwritten on the production server at the worst possible moment because a sysadmin who's been working all weekend happened to deploy a non-edited WAR because the coffee ran out on Sunday afternoon.
JNDI just happens to be the "standard" way of doing this externalization in Java, which means that new devs/admins won't need two days of training to learn the quirks of your own, home-brewn configuration system which really is quite clever but has this weird bug no one wants to delve into because it's really weird and anywho it has a pretty simple workaround, &c.
Related: What is the purpose of JNDI?