[cdi-dev] Challenge TCK test for indirect specialization rules
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
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
> If you have
> As -> Bs -> C -> D
> then only As and C account for the name and qualifier evaluation.
> On Friday, 6 June 2014, 10:17, Jozef Hartinger <jharting at redhat.com>
> 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
> 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
> of B (and thus also those from C).
> However, there are other parts of the specification for which the
> 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
> (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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev