dependent bean handling
by Mark Struberg
Hi!
I came across this in org.jboss.cdi.tck.tests.implementation.producer.method.definition.ProducerMethodDefinitionTest ,but other methods might contain something similar:
@Test
@SpecAssertions({ @SpecAssertion(section = DISPOSER_METHOD, id = "b") })
public void testStaticDisposerMethod() throws Exception {
assert getBeans(String.class, TAME_LITERAL).size() == 1;
String aString = getContextualReference(String.class, TAME_LITERAL);
Bean<String> stringBean = getBeans(String.class, TAME_LITERAL).iterator().next();
CreationalContext<String> creationalContext = getCurrentManager().createCreationalContext(stringBean);
stringBean.destroy(aString, creationalContext);
assert BeanWithStaticProducerMethod.stringDestroyed;
}
the Dependent producer gets called via BeanManager#getReference _internally_ by using a 'throw away' CreationalContext
And then you later create a _new_ CreationalContext and use this for bean.destroy.
We should rather use the original CC. As is it now, this test is on the edge of being illegal ;)
LieGrue,
strub
10 years, 5 months
- 3
- 2
Re: [cdi-dev] Challenge TCK test for indirect specialization rules
by Mark Struberg
> 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.
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...
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(a)redhat.com> wrote:
Subject: Re: [cdi-dev] Challenge TCK test for indirect specialization rules
To: "Mark Struberg" <struberg(a)yahoo.de>, cdi-dev(a)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/%23j...
>
> txs and LieGrue,
> strub
>
>
_______________________________________________
> cdi-dev mailing list
>
cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
10 years, 5 months
- 3
- 2