Tomcat连接Oracle JNDI失败主因是ojdbc驱动未放$CATALINA_HOME/lib、JNDI名不匹配或配置文件层级错乱；驱动须由Catalina类加载器加载，代码lookup必须用"ja va:comp/env/"前缀。
遇到Tomcat配置Oracle JNDI数据源失败，先别急着怀疑自己的代码。实际上，十有八九的问题都出在部署环节——要么是驱动放错了地方，要么是名字没对上，再不然就是配置文件层级搞混了。说白了，不是逻辑不对，而是链路断了。
Oracle JDBC 驱动必须放在 $CATALINA_HOME/lib 目录下
这里有个关键点：Tomcat启动时，是由Catalina类加载器负责加载全局资源的。所以，你把ojdbc8.jar（或者ojdbc6.jar）放在应用的WEB-INF/lib里，对JNDI数据源来说，是完全不起作用的。驱动类，不管是老版本的oracle.jdbc.driver.OracleDriver还是新版的oracle.jdbc.OracleDriver，都必须能被Tomcat的系统类加载器找到才行。
如果放错了位置，通常会看到这样的报错：Cannot create JDBC driver of class '' for connect url 'null'，或者更直接的ClassNotFoundException: oracle.jdbc.driver.OracleDriver。
- 确认驱动版本：Oracle 12c及以上，推荐使用
ojdbc8.jar；如果是11g，可以用ojdbc6.jar。至于classes12.jar这种老古董，就别再用了。 - 认准唯一路径：必须是
$CATALINA_HOME/lib/ojdbc8.jar。既不是WEB-INF/lib/，也不是$CATALINA_HOME/common/lib/（这个目录在Tomcat 7之后就已经废弃了）。 - 避免冲突：记得把项目里多余的
ojdbc*.jar删掉，否则很容易引发LinkageError或者类加载冲突，到时候排查起来更头疼。
server.xml 里配全局资源，context.xml 里只做引用
配置文件的角色一定要分清。全局数据源的定义，必须放在$CATALINA_HOME/conf/server.xml文件的$CATALINA_HOME/conf/context.xml（对所有应用生效）或者META-INF/context.xml（只对单个应用生效）里进行。这两者的关系不能颠倒。
一个典型的错误是：直接把context.xml，却忘了指定factory。结果就是，Tomcat会使用默认的DBCP连接池，而它的参数很可能与Oracle驱动不兼容。
- 全局定义示例（
server.xml）： - 对应引用（
context.xml）： - 别忘了
web.xml的声明：jdbc/oracle ja vax.sql.DataSource Container
Ja va 代码里 lookup 必须带 ja va:comp/env/ 前缀
在代码里进行JNDI查找时，用的名字可不是你在配置文件name属性里写的那个字符串本身，而是容器帮你拼接好的完整路径。前缀写错了，NoInitialContextException或者空指针就找上门了。
这里还有个容易踩的坑：很多开发者习惯在IDE（比如Eclipse）里直接“Run on Server”。这时候，Tomcat读取的其实是workspace下Servers/Tomcat vX.X Server at localhost-config/目录里的配置文件，而不是你本地的$CATALINA_HOME/conf/。改错了地方，等于白忙活一场。
- 正确的lookup写法：
ctx.lookup("ja va:comp/env/jdbc/oracle") - 错误的写法：
ctx.lookup("jdbc/oracle")或者ctx.lookup("ja va:global/jdbc/oracle")（后者是Ja va EE的全局命名空间，别搞混了）。 - 调试小技巧：可以在servlet的init()方法里打印一下
ctx.list("")，看看你定义的名字是否真的成功绑定到了资源上。
最后，再提一个经常被忽略的细节：验证查询（validationQuery）和连接测试时机。Oracle数据库不支持简单的SELECT 1，必须写成SELECT 1 FROM DUAL或者SELECT SYSDATE FROM DUAL。另外，如果你设置了testOnBorrow="true"却没有配置validationQuery，那么连接池很可能会静默地返回一个已经失效的连接，问题就藏得更深了。
