I understand the 4.3.1. subsection in the following way: If X -> Z -> Y, then X specializes both Y and Z. Therefore X inherits the qualifiers and bean name of Y, but also X inherits the qualifiers and bean name of Z. The problem is that there are 2 rules for what the qualifiers of X should include: • all qualifiers of Y, together with all qualifiers declared explicitly by X, and • all qualifiers of Z, together with all qualifiers declared explicitly by X, which might seem to be a contradiction. However, it does not say that the qualifiers of X do NOT include anything else (include => mathematical subset) so the option for including all of them wins IMO. If the intention was as Mark mentioned, then a clarification is strongly needed. If the intention was not to ignore the beans in-between, then the rule for indirect specialization seems quite redundant to me. Indeed, if X -> Z -> Y, then Z specializes Y. Therefore Z inherits the qualifiers and bean name of Y. Furthermore, X inherits the qualifiers and bean name of Z (because X -> Z), so X inherits the qualifiers and bean name of Y (transitively). And what about the restrictions and definition errors? No worry about that. When you think about it: - If the set of the types of X (denote Types(X)) has to be a subset of Types(Z), and Types(Z) ⊆ Types(Y), then also Types(X) ⊆ Types(Y). - If Y has a bean name and X declares a bean name explicitly, then Z inherits the Y's bean name and the problem is still detected. WDYT? Matus ----- Original Message ----- From: "Mark Struberg" <struberg(a)yahoo.de&gt; To: cdi-dev(a)lists.jboss.org Sent: Tuesday, June 3, 2014 10:37:00 AM Subject: [cdi-dev] Challenge TCK test for indirect specialization rules Hi! The question is about org.jboss.cdi.tck.tests.inheritance.specialization.simple.SimpleBeanSpecializationTest#testSpecializingBeanHasNameOfSpecializedBean and a few other tests in there. Imo they directly contradict 4.3.1 of the spec: ------- Formally, a bean X is said to specialize another bean Y if either: • X directly specializes Y, or • a bean Z exists, such that X directly specializes Z and Z specializes Y. Then X will inherit the qualifiers and bean name of Y: • the qualifiers of X include all qualifiers of Y, together with all qualifiers declared explicitly by X, and • if Y has a bean name, the bean name of X is the same as the bean name of Y. ------- in this wording the 'intermediate class' Z in the inheritance chain X -> Z -> Y intentionally gets ignored imo. It explicitly doesn't say that 'all @Specializes up in the chain' do account for the name and qualifiers. To me it reads like the 'last' (outermost) @Specializes and the 'first' non-specializes beans do count. All @Specializes beans in-between get ignored when it comes to @Named and @Qualifier resolution. There was imo also a test for it in the CDI-1.0 TCK which we did successfully pass. But obviously this got rewritten to a different behavior. Here is the transcript of my discussion with martin and jozef so far: http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23j... txs and LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

On 06/03/2014 11:48 AM, Matus Abaffy wrote: The way indirect specialization is defined in the spec is equivalent to saying that "specialization" relation is transitive. Having A specializes B and B specializes C that means that also "A specializes C" holds true. I agree that when looking at qualifiers and name only, this "A specializes C" relation may seem redundant. Relations "A specializes B" and "B specializes C" themselves guarantee that B contains all the qualifiers of C, A contains all the qualifiers of B (and thus also those from C). However, there are other parts of the specification for which the fact that both "A specializes B" and "A specializes C" hold true is important. For example, take section 5.1.2. It says: "A bean is said to be enabled if it is not specialized by any other enabled bean". Now it makes a difference whether we consider specialization transitive (A specializes C relation exists) or not as it influences whether C ends up being enabled or not. Transitive case: Both B and C are specialized by A and thus only A remains enabled. Non-transitive case: A is enabled. B is specialized by A this B is not enabled. C is only specialized by B, which is *not enabled* thus C remains enabled. Now having both A and C enabled at the same time is clearly wrong and goes against the whole purpose of specialization. Instead of replacing C with A we end up we both beans enabled. I think there is no doubt now that non-transitive specialization does not fit the CDI spec. In addition, I hope this makes it clear why transitivity of specialization is not redundant. Jozef

On 06/06/2014 11:10 AM, Mark Struberg wrote: "A bean is said to be enabled if it is not specialized by any other enabled bean". Therefore, whether A extends C or not is irrelevant. What matters is whether A specializes C or not. Therefore, I am going to assume that you meant to write: "A still (indirectly) specializes C, thus C is not enabled". This is right. But this is exactly the transitive case, not the non-transitive one :-)

And here we go doing a full cycle back to my initial statement. From what I (and Pete as well) do remember, the reason for 4.3.1 is that it should behave different to what Jozef says.  4.3.1 is not unnecessary bollocks but is worded that way because the 'intermediate' specialized bean is INTENTIONALLY left out of the equation. This is why it is NOT unnecessary but indeed NEEDED and totally makes sense.  And if you look at Weld 1.x then you will see that old Weld versions did EXACTLY work that way as well.  LieGrue, strub On Tuesday, 10 June 2014, 12:39, Matus Abaffy <maabaffy(a)redhat.com&gt; wrote: specialized by B, which is *not enabled* thus C remains enabled. Now