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

Pete Muir pmuir at redhat.com
Wed Jun 4 09:10:31 EDT 2014

I think Matus’ description is correct. I looked at the Weld 1.0 code, and I believe it will do what Matus describes.

It would also be highly weird that if you added a parent class to the bean that has been specialised, that the name would magically change.

On 4 Jun 2014, at 07:43, Martin Kouba <mkouba at redhat.com> wrote:

> Dne 3.6.2014 14:42, Mark Struberg napsal(a):
>>> if the intention was not to ignore the beans in-between, 
>>> then the rule for indirect specialization seems quite redundant to me.
>> Exactly. Also please note that we usually define the things which shall work and do not define all things which are excluded. And if we do, then we define '... a DeploymentError has to be thrown' or similar.
>> The complete indirect specialization section would be totally redundant and thus useless if leaving out all 'intermediate' @Specialized beans would not have been intended.
>> If it would have been intended as 'transitive' then this could have been written much easier.
>> Please also note that the TCK for CDI-1.0 did NOT cover this in that way and also old Weld implementations did not behave that way.
> Not an argument. CDI TCK 1.0 did not cover a lot of things (compare ~830
> tests in TCK 1.0 vs ~1530 tests in TCK 1.1) and many parts were not
> covered properly. The same for RI - there was a lot of bugs in weld 1.x.
>> To me this seems to be purely an introduction of Weld-2.0 but it's neither backed by the spec nor by the old TCK...
> I do think it is covered by the spec. If we get some reasonable
> arguments and acknowledgment from EG we're ready to fix/exclude the tests.
>> So please remove the respective tests from the TCK and let's file this into non-portable. It's not ok to have a TCK test for things which are neither backed by the spec nor did work that way in various CDI-1.0 implementations (including Weld itself).
>> LieGrue,
>> strub
>> --------------------------------------------
>> On Tue, 3/6/14, Jozef Hartinger <jharting at redhat.com> wrote:
>> Subject: Re: [cdi-dev] Challenge TCK test for indirect specialization rules
>> To: "Mark Struberg" <struberg at yahoo.de>, cdi-dev at lists.jboss.org
>> Date: Tuesday, 3 June, 2014, 12:05
>> The way I read it is that
>> the "indirect specialization" part is just a 
>> different way of saying that specialization is
>> transitive. From that it 
>> is apparent that
>> you cannot just leave out the bean in the middle.
>> Jozef
>> On
>> 06/03/2014 10:37 AM, Mark Struberg wrote:
>>> Hi!
>>> The question is about
>> org.jboss.cdi.tck.tests.inheritance.specialization.simple.SimpleBeanSpecializationTest#testSpecializingBeanHasNameOfSpecializedBean
>>> and a few other tests in there.
>>> Imo they directly
>> contradict 4.3.1 of the spec:
>>> -------
>>> Formally, a
>> bean X is said to specialize another bean Y if either:
>>> • X directly specializes Y, or
>>> • a bean Z exists, such that X directly
>> specializes Z and Z specializes Y. Then X will inherit the
>> qualifiers and bean name of Y:
>>> • the
>> qualifiers of X include all qualifiers of Y, together with
>> all qualifiers declared explicitly by X, and
>>> • if Y has a bean name, the bean name of
>> X is the same as the bean name of Y.
>> -------
>>> in this
>> wording the 'intermediate class' Z in the
>> inheritance chain X -> Z -> Y intentionally gets
>> ignored imo.
>>> It explicitly doesn't
>> say that 'all @Specializes up in the chain' do
>> account for the name and qualifiers.
>>> To me it reads like the 'last'
>> (outermost) @Specializes and the 'first'
>> non-specializes beans do count. All @Specializes beans
>> in-between get ignored when it comes to @Named and
>> @Qualifier resolution.
>>> There was imo
>> also a test for it in the CDI-1.0 TCK which we did
>> successfully pass. But obviously this got rewritten to a
>> different behavior.
>>> Here is the
>> transcript of my discussion with martin and jozef so far:
>>> http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-06-03.log.html
>>> txs and LieGrue,
>>> strub
>> _______________________________________________
>>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

More information about the cdi-dev mailing list