为什么生产者不会在CDI中继承

Question

鉴于以下课程

    private static class ProducedInSubClass {
    }

    private static class ProducedInSuperClass {
    }

    public static class SuperClass {    
        @Produces
        public ProducedInSuperClass producedInSuperClass = new ProducedInSuperClass();
    }

    public static class SubClass extends SuperClass {
        @Produces
        ProducedInSubClass producedInSubClass = new ProducedInSubClass();
    }

   public static class BeanWithSubClass {          
        @Inject
        SubClass subClass;
        @Inject
        ProducedInSuperClass producedInSuperClass;
        @Inject
        ProducedInSubClass producedInSubClass;
   }

ProducedInSuperClass的注入仍然不满意.这与CDI-Spec第4.2章一致,我知道.

为了使这项工作,我需要扩展SubClass

 @Produces
 ProducedInSuperClass producedInSuperClassInSubClass = producedInSuperClass;

任何人都可以解释一下吗？为什么Injects,Annotations Interceptors ...继承但不是生产者？

Answer 1

为什么......继承而不是生产者？

摘自@Produces 的 JavaDoc：

bean 子类不继承生产者方法和字段。

如果生产者方法和字段将被继承，那么将存在多个 bean ......有资格注入到CDI 视为不明确依赖的注入点。

另一方面，CDI 支持生产者方法专业化：

@Mock
public class MockShop extends Shop {

   @Override @Specializes
   @Produces
   PaymentProcessor getPaymentProcessor() {
      return new MockPaymentProcessor();
   }

   @Override @Specializes
   @Produces
   List<Product> getProducts() {
      return PRODUCTS;
   }

   ...

}

Answer 2

你有没有理由只操作静态类？生产者需要放在要识别的实际CDI bean上.你的样本是从上下文中撕裂的,所以我不能说它们是否真的被认为是bean.

但是,将样本转移到非静态测试用例(有一些@Vetoed bean和生产者),它将按照您的预期运行 - 两个生产者都可以找到并生成可注射的bean.因此,您可能需要共享一个完整的可重复样本,我们可以从那里开始.

我怀疑你问的继承不是这里的实际问题. 无论如何,它的设计就像CDI 1.0那样,因此找到一个讨论就好了(至少没有JIRA问题,我确实在那里检查过).但是有一个原因立即浮现在脑海中 - 假设生产者的继承已经存在.然后你的上面的场景将有一个生产者ProducedInSuperClassin,SuperClass但由于继承也在SubClass.假设都是合法的注射(没有通过专业化禁用),那么你现在面临一个不明确的依赖例外,因为你有两个生产者相同的bean类型相同的带豆预选赛,因为SuperClass和SubClass是两个不同的豆类,都含有一个制片人.我想说这是禁止生产者继承的公平原因.此外,仍然继承,你可以覆盖子类中的方法,并出现更多的问题 - 你保持两者还是禁用原始的？如果你保留它们,那么新方法的限制是什么？如果您决定使用其中@Vetoed一种豆类,该怎么办？

从我的角度来看,这只是一个设计决定.可能到位以防止进一步混淆.虽然我知道这不是答案,所以你可能正在寻找,质疑如此古老的设计很少有更准确的答案:-)