you are wrong in quite a few ways imo:

> 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.

wrong, A still (indirectly) extends C, thus C is not enabled.

The same is btw true if you have 

As -> B -> C -> D
(s indicates @Specialized)

In this case A is the only enabled one. B, C and D are all disabled.
This doesn't need anything special regarding indirect specialization.



The way indirect specialization is defined in the spec is equivalent to
> saying that "specialization" relation is transitive.

4.3.1 does explicitly rule out transitivity for @Specialized layers 'in-between'...

If you have 

As -> Bs -> C -> D

then only As and C account for the name and qualifier evaluation.

LieGrue,
strub



On Friday, 6 June 2014, 10:17, Jozef Hartinger <jharting@redhat.com> wrote:



On 06/03/2014 11:48 AM, Matus Abaffy wrote:
> If the intention was not to ignore the beans in-between, then the rule for indirect specialization seems quite redundant to me.

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