Java17+Spring6迁移Jakarta EE后IBM MQ客户端模式2035权限错误

针对你从Java8/Spring5/Java EE迁移到Java17/Spring6/Jakarta EE后，使用IBM MQ Jakarta客户端（com.ibm.mq.jakarta.client:9.4.1.0）出现的2035未授权错误，结合开发环境用SecExit认证通过但创建监听器失败的场景，给出以下排查方向：

1. 精准定位权限不足的资源 #

2035错误核心是操作特定MQ资源时权限缺失，既然连接阶段认证通过（错误账号密码会触发2009），重点排查队列监听器涉及的资源权限：

• 确认当前认证用户对目标业务队列是否具备GET（消费场景）或PUT（生产场景）权限，同时检查是否有INQ权限（监听器初始化时可能需要查询队列元数据）
• 排查用户是否需要队列管理器层面的额外权限，比如对SYSTEM.ADMIN.COMMAND.QUEUE的访问权限（部分监听器启动逻辑会触发系统队列查询）

2. 验证MQ客户端认证上下文传递逻辑 #

从Java EE客户端切换到Jakarta EE客户端，认证信息的传递机制可能存在差异：

• 检查代码中是否显式设置了ConnectionFactory的userID和password：旧代码可能依赖JVM参数或容器上下文隐式传递，新客户端可能要求显式配置
• 强制验证useMQCSPauthentication参数的生效：确保通过JVM启动参数传递（-Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=false），部分SecExit实现依赖旧的MQCD认证方式，而非MQCSP
• 确认是否操作系统用户（Windows本地用户）覆盖了SecExit认证的用户：可通过客户端日志查看实际传递给MQ的用户ID，排查是否存在用户上下文被替换的情况

3. 开启MQ客户端跟踪日志锁定错误环节 #

启用MQ客户端详细日志，明确2035错误发生的具体API调用阶段：

• 添加JVM启动参数开启跟踪：

  -Dcom.ibm.mq.commonservices.trace.status=ON
  -Dcom.ibm.mq.commonservices.trace.outputName=mqclient.log
  

• 查看日志中2035错误对应的MQ操作（比如MQOPEN队列、MQSET监听器属性），精准定位是哪个资源触发的权限问题
• 日志中会显示实际使用的用户ID，确认是否与SecExit认证通过的用户一致

4. 排查Spring 6 JMS配置的兼容性问题 #

Spring 6对Jakarta EE的JMS配置逻辑有调整，需对比旧配置检查差异：

• 确认DefaultJmsListenerContainerFactory或JmsTemplate是否正确将认证信息传递给MQ连接工厂，是否存在配置遗漏（比如connectionFactory的引用错误）
• 检查Spring Security上下文是否影响MQ连接的用户ID：如果项目启用了Spring Security，需确认是否存在安全上下文传递导致用户信息被覆盖的情况
• 对比Spring 5的配置，排查是否有属性变化（如destinationResolver、pubSubDomain）导致队列访问方式改变

5. 验证SecExit与新MQ客户端的兼容性 #

你使用的biz.capitalware.mqausx.MQAUSXJ2EE是第三方安全出口，需确认其兼容性：

• 查看该SecExit的版本文档，确认是否支持IBM MQ 9.4 Jakarta客户端及Java17
• 临时绕过SecExit（若开发环境允许），直接使用QMGR本地用户认证，测试是否仍出现2035错误，排除SecExit传递用户信息异常的可能

6. 排查Java17模块化与安全策略限制 #

Java17的模块化和安全策略比Java8严格，可能间接导致权限问题：

• 若项目为模块化结构，确认module-info.java中是否声明了对MQ客户端模块的依赖：requires com.ibm.mq.jakarta.client;
• 检查Java安全策略文件是否限制了MQ客户端的权限（如读取系统属性、网络操作），导致认证或资源访问失败

内容的提问来源于stack exchange，提问作者Barat Sahdzijeu