2

鉴于我缺乏解释问题的词汇，我通过一个重现失败并帮助查找原因的示例来展示它：

public interface BaseType<P> {}
public interface DerivedType<T> extends BaseType<T> {}

public interface SomeType1 {}
public interface SomeType2 {}

@Dependent
public static class BeanClass1 implements DerivedType<SomeType1> {}

@Dependent
public static class BeanClass2 implements DerivedType<SomeType2> {}

@ApplicationScoped
public static class Test implements Serializable {

    @Inject
    private BaseType<SomeType1> field; // if not commented throws following exception during deployment: org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BaseType<SomeType1>] with qualifiers [@Default] at injection point [[field] @Inject private Test.field]. Possible dependencies [[Managed Bean [class BeanClass2] with qualifiers [@Any @Default], Managed Bean [class BeanClass1] with qualifiers [@Any @Default]]]

    @Inject
    private Instance<BaseType<SomeType1>> instance;

    @Inject
    private BeanManager bm;

    @PostConstruct
    private void postConstruct() {
        // This block outputs two bean classes and it should be only one:
        // beanClass: BeanClass1@11be5bab
        // beanClass: BeanClass2@764a72e9
        {
            Iterator<BaseType<SomeType1>> iterator = instance.iterator();
            while (iterator.hasNext()) {
                System.out.println("beanClass: " + iterator.next().toString());
        }
    }


        // And this block outputs:
        //
        // bean: Managed Bean [class BeanClass1] with qualifiers [@Any @Default]
        // beanTypes:
        //  - class BeanClass1
        //  - DerivedType<SomeType1>
        //  - class java.lang.Object
        //  - BaseType<T>
        //
        // bean: Managed Bean [class BeanClass2] with qualifiers [@Any @Default]
        // beanTypes:
        //  - DerivedType<SomeType2>
        //  - class java.lang.Object
        //  - class BeanClass2
        //  - BaseType<T>
        {
            Set<Bean<?>> beans = bm.getBeans(new ParameterizedTypeImpl(BaseType.class, new Type[] { SomeType1.class }, null));
            for (Bean<?> bean : beans) {
                System.out.println("\nbean: " + bean+"\nbeanTypes: ");
                for (Type beanType : bean.getTypes()) {
                    System.out.println(" - " + beanType);
                }
            }

            bm.resolve(beans); // if not commeted throws an AmbiguousResolutionException
        }
    }
}

第二个块显示了 bean 类的 bean 类型集BeanClass1，BeanClass2根据Weld. 在那里我们发现 bean types set 包含 typeBaseType<T>而不是BaseType<SomeType1>or BaseType<SomeType2>。

所以，记住BeanClass2的间接接口对应的bean类型有类型变量而不是实际的类型参数。因此，根据本规范的最后一点， a被错误地认为可分配给。BaseType<P>WeldTSomeType2BeanClass2BaseType<SomeType1>

这是期望的行为还是错误？有解决方法吗？是否在新Weld版本中修复。

测试在使用 maven 工件 org.jboss.as:jboss-as-weld:7.1.1 的 JBoss AS 7.1.1 上执行

编辑：我认为这个问题的原因不是第一个答案建议的类型擦除（它已被删除），而是Weld. 生成 bean 类型所需的所有信息在运行时都可用。我猜这个错误是当Weld通过反射生成bean类的bean类型时。类型变量解析应该是递归的，显然不是。

我确信生成间接接口的 bean 类型所需的信息在运行时可用，因为我制作并测试了一个使用库完成此任务的方法 - 几年前我为内存高效的 java 序列化程序制作了 - 幸运的是它有一个函数这正是我们需要的：Type为 java 类的每个祖先生成/获取实例，递归解析类型变量。我试图将涉及的方法放在这里，但粘贴代码时出现格式问题；图书馆很长而且记录不充分的事实让我有理由放弃。

至少，为了说明如何解析间接接口的类型变量的本质，我编写了以下代码。它仅适用于特定类，但可以通过一些努力进行概括：

public static Set<Type> getActualInterfacesOfBeanClass1() {
    Set<Type> actualInterfaces = new HashSet<>();

    ParameterizedType directInterface = (ParameterizedType) BeanClass1.class.getGenericInterfaces()[0]; // = DerivedType<SomeType1>  ; assumes only one interface is extended
    actualInterfaces.add(directInterface);

    // because ParameterizedType doesn't have a method like Class.getGenericInterfaces(), we have to do it by hand
    Type indirectInterface; // = BaseType<SomeType1>
    {
        Class<?> directInterfaceRaw = (Class<?>) directInterface.getRawType(); // = DerivedType<T>
        Map<String,Type> resolutionMap = new HashMap<>(); // = { T -> SomeType1 }
        for( int i=0; i<directInterfaceRaw.getTypeParameters().length;++i) {
            resolutionMap.put(directInterfaceRaw.getTypeParameters()[i].getName(),directInterface.getActualTypeArguments()[i]);
        }

        ParameterizedType indirectInterfaceUnresolved = (ParameterizedType) directInterfaceRaw.getGenericInterfaces()[0]; // = BaseType<T> ;  assumes only one interface is extended
        ArrayList<Type> resolvedParameters = new ArrayList<>(); // = { SomeType1 }
        for(Type param : indirectInterfaceUnresolved.getActualTypeArguments()) {
            Type resolvedParam;
            if( param instanceof TypeVariable) {
                resolvedParam = resolutionMap.get(((TypeVariable<?>)param).getName());
            } else {
                resolvedParam = param;
            }
            resolvedParameters.add(resolvedParam);
        }
        indirectInterface = new ParameterizedTypeImpl(indirectInterfaceUnresolved.getRawType(), resolvedParameters.toArray(new Type[resolvedParameters.size()]),indirectInterfaceUnresolved.getOwnerType());
    }
    actualInterfaces.add(indirectInterface);

    return actualInterfaces;
}

我希望这避免相信类型擦除是导致此问题的原因。

4

2 回答 2

1

我认为这是一个限制。

如果我做对了，您的目标是通过注入和/或生成您的泛型类型来使 CDI 与泛型一起使用。

我前段时间做过同样的事情，发现这是Java的限制。由于 Java 使用类型擦除来实现泛型，因此 CDI 无法正确处理泛型注入。

最后，你发现你有BaseType<T>，但由于这个限制，CDI 只能注入具体类型，比如BaseType<SomeType1>.

检查我的情况，我认为这有点简单但原理相同：

界面

public interface Persistable implements Serializable {
    ... 
}

不工作

@Named
@RequestScoped
public class MyBean<T extends Persistable> {

    @Inject
    private T model;
}

作品

@Named
@RequestScoped
public class MyBean<T extends Persistable> {

    @Inject
    private Persistable model;

}

另请查看 WELD/CDI 规范负责人的这篇文章。

所以，参数化 bean 没有问题，问题在于最终有一个像你的BaseType<T>.

如果你能给他们一个具体的类型，这应该按照我提到的帖子中的建议工作。不理想，但...

我希望它有所帮助。

于 2013-03-23T07:40:16.673 回答
1

我发现解决此错误的侵入性最小的方法是，对于C应该具有表单T<A>但使用类型变量Weld错误地更改实际类型参数的 bean 类的每个参数化 bean 类型A，创建一个新的空接口，扩展T<A>并添加这个Pilot 接口到实现的接口列表C和间接扩展的任何其他 bean 类T<A>。

特别是，对于上面的代码，bean 类BaseType<SomeType1>的 bean 类型BeanClass1被错误地更改为Weldto BaseType<T>。因此，解决该问题所需的试点界面将是：

public interface PilotInterface1 extends BaseType<SomeType1> {}

应用了解决方法的 bean 类将是：

@Dependent
public static class BeanClass1 implements DerivedType<SomeType1>, PilotInterface1 {}

我建议将所有试点接口放在一个单独的包或文件中，以便在修复错误时轻松删除它们。

于 2013-04-08T17:44:46.080 回答