在 CDI/Weld 中如何解决子类型和泛型？

Question

我在运行 Weld 2.2.6 Final 的 Wildfly 8.2.1 Final 工作。

给定

@Entity
public class Fruit{ ... }

@Entity
public class Apple extends Fruit{ ... }


public interface Repository<T extends Identifiable> { ... }


public interface Identifiable { String getId(); }

和

@ApplicationScoped
public class FruitCDIDelegateRepository implements Repository<Fruit>, SearchableRepository<Fruit> { @EJB private FruitRepository repo; }

@Stateless
@LocalBean
@Typed(FruitRepository.class)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class FruitRepository extends PersistenceRepository<Fruit> implements SearchableRepository<Fruit, FruitCriteria> {

最后两个存储库是直接从书中构建的 Java 中的持续企业开发 作者：Andrew Lee Rubinger 和 阿斯拉克·克尼森。这是帮助 EJB 和 CDI 工作的解决方法 一起。在他们写的书中

这个 EJB 被 @Typed 到一个特定的类型以避免被 由于 CDI EJB 中的限制/错误，存储库下的 CDI 互动。 EJB Beans 总是被解析为 Repository，这意味着 两个实现 Repository 接口的 EJB 都响应 InjectionPoint @Inject Repository 并制作 InjectionPoint 模棱两可。

作为一种解决方法，我们将具有事务属性的 EJB 包装在 CDI bean 中 可以由 Type 系统使用。 EJB 被认为是一个内部 实施细节。 ConferenceCDIDelegateRepository 提供的 CDI 类型 是真正的 Repository api。

在这种情况下，其他类应该可以忽略不计。

我应该不能申报吗

@Inject
Repository<Apple> repository;

在一个类中并获得一个FruitRepository（CDIDelegate 种）？类似情况

@Inject
Repository<Fruit> repository;

在相同的环境中产生预期的对象。

Answer 1

您可以在没有包装器的情况下注入@Statless Repository。

@RequestScoped
public class Service {

    @Inject
    FruitRepository fruitRepository;

    public void saveFruit(Fruit fruit){
        fruitRepository.save(fuit);
    }

}