Erreur dans l'accès privé de CDI injecté extérieur de la classe statique intérieur de la classe

Question

J'ai (dans une version minimaliste) le CDI géré les haricots dans JBoss EAP 6.0.1

@ApplicationScoped
public class Outer {
    private final List<String> values = new ArrayList<String>();

    public void printValues() {
        System.out.println("Values: " + values);
    }

    private void addValue(String value) {
        values.add(value);
    }

    public static class Inner {

        @Inject
        private Outer outer;

        public void addFoo() {
            outer.addValue("foo");
        }
    }
}

Et le code suivant pour tester cela (Ne pas poser la question pourquoi.C'est seulement pour cette vitrine.):

@Inject
Outer outer;

@Inject
Outer.Inner inner;

public void test() {
    inner.addFoo();
    outer.printValues();
}

Je reçois une puissance de:

Values: {}

où je me serais attendu à la valeur foo.

Une enquête ultérieure a révélé que l'appel à private void addValue accède à une version de la values attribut qui vit dans un cordon de Soudure-Proxy généré de Outer alors que l'appel à public void printValues accède à la véritable attribut du réel managed bean instance.

Pour rendre les choses encore plus confuses:Si je change le niveau d'accès de addValue pour l'un de package, protected ou public tout fonctionne comme prévu.

Mais le but de l'intérieur de la classe dans mon cas était de faciliter la méthode d'être privé de sorte que d'autres CDI clients de l'Extérieur ne peut pas appeler la méthode.Et maintenant c'est la seule chose qui ne fonctionne pas :D

Toute idée de ce qui est mal?Est-ce un bug de la Soudure?

Answer 1

Actuellement, tous les CDI des fournisseurs d'utiliser des proxys (il n'est pas requis par la spécification, mais c'est la façon dont les trois impls ont été faites) pour l'injection de tout non pseudo-objets dans l'étendue.Si l'Extérieur a été @DependantScoped Je suis assez sûr qu'elle fonctionne de la manière que vous voulez.Les procurations sont créés naturellement des sous-classes de vos classes, de sorte que l'appel d'une méthode sur un injectée objet n'est pas d'aller travailler.Honnêtement, je suis surpris qu'il ne soit pas exploser.