Jakarta EE 8单体应用CDI构造注入无参构造函数问题咨询

首先，咱们得先弄明白为什么WildFly（底层用Weld作为CDI实现）会抛出这个错误——哪怕你不打算集群部署。

核心原因：CDI代理机制的要求 #

SessionScoped这类有状态的上下文作用域，CDI需要通过代理来管理bean的生命周期和上下文访问。Weld默认使用基于类的代理（比如CGLIB），这种代理方式需要目标类提供一个无参构造函数：因为代理类是目标类的子类，它需要先调用父类的无参构造来初始化实例，再注入依赖。哪怕你不需要序列化，SessionScoped的bean本身就需要代理来实现延迟加载、上下文关联等功能，所以这个要求和集群无关。

关于enableUnsafeProxies方案的优缺点 #

你提到的添加META-INF/org.jboss.weld.enableUnsafeProxies文件确实能解决问题，它的作用是让Weld绕过类代理的无参构造检查，直接通过反射实例化bean（不生成子类代理）。但它并不是最佳实践：

• 优点：快速解决问题，不需要修改业务代码
• 缺点：
  • 存在兼容性风险：如果你的bean是final类，或者包含final方法，后续添加拦截器、装饰器时，这些CDI特性会失效（因为没有代理来拦截方法调用）
  • 不符合CDI规范的推荐代理方式，长期来看可能在版本升级时出现兼容性问题

更推荐的最佳实践方案 #

1. 添加protected无参构造函数

给BeanA、BeanA1、BeanA2添加一个protected访问权限的无参构造函数，既满足Weld的代理要求，又能避免外部代码直接实例化bean（保持构造注入的封装性）：

@SessionScoped
public class BeanA implements Serializable {
    private final BeanA1 bean1;
    private final BeanA2 bean2;

    @Inject
    public BeanA(final BeanA1 bean1, final BeanA2 bean2) {
        this.bean1 = bean1;
        this.bean2 = bean2;
    }

    // 供CDI代理使用的protected无参构造
    protected BeanA() {
        // 调用带参构造并传入null，保证final字段初始化
        this(null, null);
    }
}

这个方案是CDI规范推荐的方式，完全兼容所有CDI特性，也不会破坏构造注入的最佳实践。

2. 基于接口的JDK动态代理

让SessionScoped的bean实现一个接口，然后在依赖注入时使用接口类型而非具体类。比如：

// 定义业务接口
public interface BeanAInterface {
    // 声明BeanA的业务方法
    void doSomething();
}

// 实现类
@SessionScoped
public class BeanA implements BeanAInterface, Serializable {
    private final BeanA1 bean1;
    private final BeanA2 bean2;

    @Inject
    public BeanA(final BeanA1 bean1, final BeanA2 bean2) {
        this.bean1 = bean1;
        this.bean2 = bean2;
    }

    @Override
    public void doSomething() {
        // 业务逻辑实现
    }
}

// ViewController中注入接口类型
@Named @ViewScoped
public class ViewController implements Serializable {
    private final BeanAInterface bean;

    @Inject
    public ViewController(final BeanAInterface bean) {
        this.bean = bean;
    }
}

Weld会使用JDK动态代理（基于接口），这种代理方式不需要目标类的无参构造函数。适合本来就有接口抽象需求的场景，但会增加一些代码量。

总结 #

虽然enableUnsafeProxies能快速解决当前问题，但从长期维护和规范兼容性来看，添加protected无参构造函数是最稳妥的最佳实践；如果你的项目本来就有接口分层的设计，基于接口的代理方式也是不错的选择。

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