OWB+TomEE+JSF 2.3.10启动时CDI注入失败问题排查

一、除配置外导致@Default限定符错误的常见原因 #

1. Bean类的CDI注解缺失或不规范 #

• 确认SelcodeList类已被正确标记为CDI Bean：如果缺少@Named、@ApplicationScoped等作用域注解，OWB不会将其纳入CDI管理范围。注意：仅使用JSF的@ManagedBean无法被CDI容器识别，这类Bean只能通过JSF的@ManagedProperty注入，而非@Inject。
• 若SelcodeList是接口，需确保其实现类要么无额外限定符（默认自带@Default），要么显式标注@Default，否则CDI无法匹配注入点的@Default要求。

2. 类路径扫描异常 #

• 检查SelcodeList所在包是否被OWB的扫描规则排除：比如项目打包时该类未被纳入WEB-INF/classes，或依赖jar包未正确放置在WEB-INF/lib下。
• 排查是否存在多CDI容器冲突：若项目中同时引入OWB和Weld依赖，TomEE默认的OWB容器可能出现扫描逻辑混乱，导致Bean无法被识别。

3. 注入点与Bean的类型不匹配 #

• 验证SearchAction中selcodeList字段的类型：如果是SelcodeList接口，但存在多个实现类且未明确默认候选，CDI会因为歧义无法注入；如果是具体类，需确保类本身符合CDI Bean的要求。
• 泛型类型解析问题：若注入的是List<SelcodeList>这类泛型，CDI的类型推断可能失效，需通过@Typed注解显式指定目标类型。

4. 作用域兼容性问题 #

• 若SelcodeList的作用域（如@RequestScoped）短于SearchAction的作用域（如@ApplicationScoped），CDI无法直接注入短作用域Bean到长作用域Bean中，需改用@Inject Instance<SelcodeList>延迟获取实例。

5. 类加载器冲突 #

• 检查项目中是否存在重复的SelcodeList类：比如多个jar包中包含同包同名的类，类加载器加载了非预期版本的类，导致CDI无法识别正确的Bean元数据。
• 排查TomEE共享库（lib目录）与项目WEB-INF/lib的依赖冲突：若JSF、CDI相关jar版本不一致，可能破坏容器的Bean扫描逻辑。

二、显式添加@Default能缓解部分问题的原因 #

CDI规范中，@Default是所有无显式限定符Bean的隐含限定符，但在以下场景中，显式添加该注解可修复识别异常：

• OWB实现的特殊逻辑：对于部分特殊Bean（如XML配置的Bean、或混合使用多种注解的Bean），OWB可能未正确自动添加隐含的@Default限定符，显式标注可补全元数据，让容器正确识别。
• 多限定符共存场景：若Bean同时带有自定义限定符，显式添加@Default可明确该Bean属于@Default候选组，匹配仅要求@Default的注入点。
• 缓存覆盖：修改配置后容器缓存未清空时，显式添加注解会触发类的重新扫描和元数据生成，覆盖旧的缓存信息，解决配置变更未生效的问题。

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