JSF同名Backing Bean跨WAR模块类路径解析安全性问询

核心结论 #

当前正常运行不是偶然情况，Java EE的类加载机制和JSF的命名Bean解析逻辑能稳定保证每个WAR模块的JSF文件找到对应模块内的Backing Bean，frontend2.xhtml中的${back}绝对不会解析到另一个模块的com.company.operator.Back。

具体原因 #

1. WAR模块的类加载隔离性 #

EAR包中的每个WAR模块都拥有独立的类加载器，属于严格的模块级隔离：

• operator-module的类加载器只会加载自身WEB-INF/classes和WEB-INF/lib下的类，com.company.operator.Back仅由这个类加载器负责加载；
• customer-module的类加载器同理，只加载本模块内的com.company.customer.Back。
  两个类加载器加载的同名类（不同包路径）是完全独立的个体，不会出现互相干扰的情况。

2. JSF命名Bean的解析范围 #

JSF的命名Bean（无论是@Named注解还是传统的managed-bean配置），默认解析范围被限定在当前模块的类加载上下文内：

• frontend1.xhtml在operator-module中解析${back}时，只会在该模块类加载器可访问的Bean中查找，必然命中com.company.operator.Back；
• frontend2.xhtml在customer-module中解析时，只会匹配到自身模块的com.company.customer.Back。

3. IDE识别的合理性 #

IntelliJ能正确识别引用，是因为它会根据JSF文件所在的模块，关联对应模块的类路径进行解析，这个逻辑和运行时的类加载规则完全一致，所以IDE的识别结果可以直接对应运行时的实际行为。

风险提示 #

如果后续对项目做以下修改，可能打破现有隔离状态：

• 将某个Backing Bean放到EAR的共享lib目录（该目录由共享类加载器负责加载），此时两个模块都能访问到这个Bean，可能出现命名冲突；
• 修改JSF的Bean解析配置，强制开启跨模块查找（这种配置在实际项目中极少用到）。

内容的提问来源于stack exchange，提问作者János Balázs