operationnotsupportedexception 在 jndi 查找时抛出，是因为底层 jndi 实现不支持该操作，典型原因是非 java ee 环境（如 spring boot jar 启动）中调用 java:comp/env/ 路径，而标准 jdk 不识别此命名空间，且未配置对应上下文工厂。
为什么 OperationNotSupportedException 会在 JNDI 查找时抛出
这不是你代码写错了，而是底层 JNDI 实现压根不支持你调用的操作。典型场景是：你在非 Java EE 环境（比如 Spring Boot 普通 jar 启动）里写了 new InitialContext().lookup("java:comp/env/jdbc/myDS")，JVM 找不到对应的服务提供者，InitialContext 返回了一个空壳实现（如 com.sun.jndi.cosnaming.CNCtx 或默认的 com.sun.jndi.fscontext.RefFSContextFactory），一调用 lookup() 就直接抛 OperationNotSupportedException。
关键点在于：java:comp/env/... 是 Java EE 容器（Tomcat、WildFly）绑定的命名空间，标准 JDK 的 JNDI 不认识这个前缀，也不提供绑定能力。
- Spring Boot 默认没启动 JNDI 支持，
java:comp/env查找必然失败 - 本地测试时用
fscontext.jar或ldap://做外部 JNDI 服务，路径必须是绝对合法的 URL 形式（如ldap://localhost:10389/o=example），不能混用容器专属路径 - Tomcat 中启用 JNDI 需显式配置
conf/context.xml和资源定义，且应用要打包为 war 部署——jar 包方式绕不过去
如何判断当前环境是否真有可用的 JNDI 上下文
别猜，直接查 InitialContext 底层用了啥工厂和提供者：
Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.naming.java.javaURLContextFactory");
// 或尝试打印当前默认工厂
System.out.println(System.getProperty("java.naming.factory.initial"));
// 再试构建并检查是否报错
try {
Context ctx = new InitialContext(env);
System.out.println("Ctx class: " + ctx.getClass().getName());
} catch (NamingException e) {
e.printStackTrace(); // 看具体是哪个类抛的 <code>OperationNotSupportedException</code>
}
- 如果
java.naming.factory.initial是空或com.sun.jndi.rmi.registry.RegistryContextFactory，说明没配对的上下文工厂，lookup()必挂 -
org.apache.naming.java.javaURLContextFactory是 Tomcat 提供的，只在 Tomcat 启动时有效；单独运行会因找不到org.apache.naming.NamingContext类而报NoClassDefFoundError - JDK 11+ 移除了
com.sun.jndi.ldap.LdapCtxFactory的默认信任机制，连 LDAP 查找都可能因证书或协议问题静默失败，不一定抛这个异常，但表现类似
替代方案：绕过 JNDI 直接获取数据源（Spring Boot 场景最常用）
绝大多数 Spring Boot 项目根本不需要 JNDI——它自带更可控的 DataSource 构建逻辑。把 application.yml 里的配置从 JNDI 切成直连：
立即学习“Java免费学习笔记（深入）”；
spring:
datasource:
url: jdbc:mysql://localhost:3306/mydb
username: root
password: pass
driver-class-name: com.mysql.cj.jdbc.Driver
- 删掉所有
@Resource(lookup = "java:comp/env/jdbc/myDS")注解，改用@Autowired DataSource - 如果旧代码强依赖 JNDI 接口（比如第三方库硬编码调用
InitialContext.lookup()），可自己注册一个轻量InitialContext实现，用SimpleNamingContextBuilder（Spring 提供）在测试或启动时 bind mock 对象 - 注意：JNDI 绑定的是引用（
Reference），不是真实对象；直连方式拿到的是真实DataSource实例，连接池行为（如 HikariCP 参数）需单独配，别指望容器代劳
真要跑 JNDI：Tomcat 下必须做的三件事
如果你确定要走容器 JNDI（比如迁移老系统），Tomcat 不是“配了就能用”，漏一步就回到 OperationNotSupportedException：
- 在
META-INF/context.xml或$CATALINA_BASE/conf/context.xml里声明资源：<Resource name="jdbc/myDS" auth="Container" type="javax.sql.DataSource" factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" ... /> - 应用
web.xml中加 resource-ref（Servlet 3.0+ 可省略，但建议留着） - 确保部署方式是 war 包——jar 包启动时 Tomcat 根本不解析
context.xml，也不会初始化java:comp/env命名空间
JNDI 不是通用命名服务，它是容器生命周期的一部分。脱离容器谈 JNDI 查找，就像在沙滩上搭积木还问为什么海水一来就垮——不是积木不行，是地方不对。
