Spring Boot @ConditionalOnMissingBean et types génériques

Y a-t-il une solution de contournement pour cela?

Malheureusement, je ne pense pas. Le problème est que les génériques en Java n'existent pas dans le bytecode compilé - ils ne sont utilisés que pour la vérification de type au moment de la compilation et ils n'existent que dans le code source. Par conséquent, au moment de l'exécution, lorsque Spring Boot voit votre classe de configuration de bean, il ne voit que deux définitions de bean qui créent toutes deux un conteneur. Il ne voit aucune différence entre eux à moins que vous ne les fournissiez vous-même en leur donnant des identifiants.

Voici une solution entièrement fonctionnelle. J'ai abandonné cette approche, mais je la poste au cas où quelqu'un la trouverait utile.

J'ai fait une annotation personnalisée:

Class<?> declaringClass = ClassUtils.forName(methodMeta.getDeclaringClassName(), context.getClassLoader());

Et une condition personnalisée à emporter avec:

@ConditionalOnMissingGenericBean(declaringClass=CustomConfig.class)

Ceux-ci me permettent de faire ce qui suit:

@Bean
@ConditionalOnMissingGenericBean(containerType=Container.class, typeParameters=Computer.class)
public Container<Computer> computerContainer() {
    return new Container<>(new Computer());
}

Les deux beans seront maintenant chargés comme ils ' re de différents types génériques. Si l'utilisateur du démarreur enregistrait un autre bean de type Container ou Container , alors le bean par défaut ne serait pas chargé, exactement comme souhaité.

Telle qu'elle est implémentée, il est également possible d'utiliser l'annotation de cette manière:

@Bean
//Load this bean only if Container<Car> isn't present
@ConditionalOnMissingGenericBean(containerType=Container.class, typeParameters=Car.class)
public Container<Computer> computerContainer() {
    return new Container<>(new Computer());
}

Remarques: Le chargement de la classe de configuration dans la condition n'est peut-être pas sûr, mais dans ce cas précis, cela peut aussi l'être ... Je n'en ai aucune idée. Je n'ai pas pris la peine d'enquêter plus avant car j'ai opté pour une approche totalement différente (interface différente pour chaque bean). Si vous avez des informations à ce sujet, veuillez commenter.

Si des types explicites sont fournis dans l'annotation, par exemple

@Bean
@ConditionalOnMissingGenericBean
public Container<Book> bookContainer() {
    return new Container<>(new Book());
}

@Bean
@ConditionalOnMissingGenericBean
public Container<Computer> computerContainer() {
    return new Container<>(new Computer());
}

, ce problème disparaît, mais ceci l'approche ne fonctionnera pas si les paramètres de type sont également génériques, par exemple Container>.

Une autre façon de garantir la sécurité serait d'accepter la classe déclarante dans l'annotation:

public class MissingGenericBeanCondition implements Condition {

    @Override
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        if (!metadata.isAnnotated(ConditionalOnMissingGenericBean.class.getName()) || context.getBeanFactory() == null) {
            return false;
        }
        Map<String, Object> attributes = metadata.getAnnotationAttributes(ConditionalOnMissingGenericBean.class.getName());
        Class<?> containerType = (Class<?>) attributes.get("containerType");
        Class<?>[] typeParameters = (Class<?>[]) attributes.get("typeParameters");

        ResolvableType resolvableType;
        if (Void.class.equals(containerType)) {
            if (!(metadata instanceof MethodMetadata) || !metadata.isAnnotated(Bean.class.getName())) {
                throw error();
            }
            //When resolving beans within the starter
            if (metadata instanceof StandardMethodMetadata) {
                resolvableType = ResolvableType.forType(((StandardMethodMetadata) metadata).getIntrospectedMethod().getGenericReturnType());
            } else {
                //When resolving beans in an application using the starter
                MethodMetadata methodMeta = (MethodMetadata) metadata;
                try {
                    // This might not be a safe thing to do. See the notes below.
                    Class<?> declaringClass = ClassUtils.forName(methodMeta.getDeclaringClassName(), context.getClassLoader());
                    Type returnType = Arrays.stream(declaringClass.getDeclaredMethods())
                            .filter(m -> m.isAnnotationPresent(Bean.class))
                            .filter(m -> m.getName().equals(methodMeta.getMethodName()))
                            .findFirst().map(Method::getGenericReturnType)
                            .orElseThrow(MissingGenericBeanCondition::error);
                    resolvableType = ResolvableType.forType(returnType);
                } catch (ClassNotFoundException e) {
                    throw error();
                }
            }
        } else {
            resolvableType = ResolvableType.forClassWithGenerics(containerType, typeParameters);
        }

        String[] names = context.getBeanFactory().getBeanNamesForType(resolvableType);
        return names.length == 0;
    }

    private static IllegalStateException error() {
        return new IllegalStateException(ConditionalOnMissingGenericBean.class.getSimpleName()
                + " is missing the explicit generic type and the implicit type can not be determined");
    }
}

C'est possible depuis Spring Boot v2.1.0.

Cette version a introduit le nouveau champ parameterizedContainer sur ConditionalOnMissingBean.

@Bean
@ConditionalOnMissingBean(value = Book.class, parameterizedContainer = Container.class)
public Container<Book> bookContainer() {
    return new Container<>(new Book());
}

@Bean
@ConditionalOnMissingBean(value = Computer.class, parameterizedContainer = Container.class)
public Container<Computer> computerContainer() {
    return new Container<>(new Computer());
}