Tomcat连接Oracle JNDI失败主因是ojdbc驱动未放$CATALINA_HOME/lib、JNDI名不匹配或配置文件层级错乱;驱动须由Catalina类加载器加载,代码lookup必须用"ja va:comp/env/"前缀。 遇到Tomcat配置Oracle JNDI数据源失败,先别
遇到Tomcat配置Oracle JNDI数据源失败,先别急着怀疑自己的代码。实际上,十有八九的问题都出在部署环节——要么是驱动放错了地方,要么是名字没对上,再不然就是配置文件层级搞混了。说白了,不是逻辑不对,而是链路断了。

长期稳定更新的攒劲资源: >>>点此立即查看<<<
$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。
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:comp/env/ 前缀在代码里进行JNDI查找时,用的名字可不是你在配置文件name属性里写的那个字符串本身,而是容器帮你拼接好的完整路径。前缀写错了,NoInitialContextException或者空指针就找上门了。
这里还有个容易踩的坑:很多开发者习惯在IDE(比如Eclipse)里直接“Run on Server”。这时候,Tomcat读取的其实是workspace下Servers/Tomcat vX.X Server at localhost-config/目录里的配置文件,而不是你本地的$CATALINA_HOME/conf/。改错了地方,等于白忙活一场。
ctx.lookup("ja va:comp/env/jdbc/oracle")ctx.lookup("jdbc/oracle") 或者 ctx.lookup("ja va:global/jdbc/oracle")(后者是Ja va EE的全局命名空间,别搞混了)。ctx.list(""),看看你定义的名字是否真的成功绑定到了资源上。最后,再提一个经常被忽略的细节:验证查询(validationQuery)和连接测试时机。Oracle数据库不支持简单的SELECT 1,必须写成SELECT 1 FROM DUAL或者SELECT SYSDATE FROM DUAL。另外,如果你设置了testOnBorrow="true"却没有配置validationQuery,那么连接池很可能会静默地返回一个已经失效的连接,问题就藏得更深了。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述