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

Jozef Hartinger jharting at redhat.com
Fri Jun 6 05:33:16 EDT 2014


On 06/06/2014 11:10 AM, Mark Struberg wrote:
> 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.
"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 :-)

>
> 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/4df78738/attachment.html 


More information about the cdi-dev mailing list