[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