[cdi-dev] Challenge TCK test for indirect specialization rules

[Mark Struberg]

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 at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140606/b544c599/attachment-0001.html