From struberg at yahoo.de Tue Jun 3 04:37:00 2014 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 3 Jun 2014 09:37:00 +0100 (BST) Subject: [cdi-dev] Challenge TCK test for indirect specialization rules Message-ID: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> 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 From mkouba at redhat.com Tue Jun 3 05:27:16 2014 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 03 Jun 2014 11:27:16 +0200 Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> Message-ID: <538D94F4.9040809@redhat.com> For the record: the TCK team does think that a bean may have "direct specialization" and "indirect specialization" relationship in the same time. In other words, for "X extends Z extends Y", where both X and Z are annotated with @Specializes, X not only "directly specializes" Z but also "indirectly specializes" Y. Beans Z and Y are ignored because they're specialized by X. However, I do agreee that some explicit wording/clarification in this area would be appropriate. Martin Dne 3.6.2014 10:37, Mark Struberg napsal(a): > 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 > From maabaffy at redhat.com Tue Jun 3 05:48:41 2014 From: maabaffy at redhat.com (Matus Abaffy) Date: Tue, 3 Jun 2014 05:48:41 -0400 (EDT) Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> Message-ID: <212784191.14555985.1401788921185.JavaMail.zimbra@redhat.com> I understand the 4.3.1. subsection in the following way: If X -> Z -> Y, then X specializes both Y and Z. Therefore X inherits the qualifiers and bean name of Y, but also X inherits the qualifiers and bean name of Z. The problem is that there are 2 rules for what the qualifiers of X should include: ? all qualifiers of Y, together with all qualifiers declared explicitly by X, and ? all qualifiers of Z, together with all qualifiers declared explicitly by X, which might seem to be a contradiction. However, it does not say that the qualifiers of X do NOT include anything else (include => mathematical subset) so the option for including all of them wins IMO. If the intention was as Mark mentioned, then a clarification is strongly needed. If the intention was not to ignore the beans in-between, then the rule for indirect specialization seems quite redundant to me. Indeed, if X -> Z -> Y, then Z specializes Y. Therefore Z inherits the qualifiers and bean name of Y. Furthermore, X inherits the qualifiers and bean name of Z (because X -> Z), so X inherits the qualifiers and bean name of Y (transitively). And what about the restrictions and definition errors? No worry about that. When you think about it: - If the set of the types of X (denote Types(X)) has to be a subset of Types(Z), and Types(Z) ? Types(Y), then also Types(X) ? Types(Y). - If Y has a bean name and X declares a bean name explicitly, then Z inherits the Y's bean name and the problem is still detected. WDYT? Matus ----- Original Message ----- From: "Mark Struberg" To: cdi-dev at lists.jboss.org Sent: Tuesday, June 3, 2014 10:37:00 AM Subject: [cdi-dev] Challenge TCK test for indirect specialization rules 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 From jharting at redhat.com Tue Jun 3 06:05:11 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 03 Jun 2014 12:05:11 +0200 Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> Message-ID: <538D9DD7.9080003@redhat.com> 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 From struberg at yahoo.de Tue Jun 3 08:42:40 2014 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 3 Jun 2014 13:42:40 +0100 (BST) Subject: [cdi-dev] Challenge TCK test for indirect specialization rules Message-ID: <1401799360.48396.YahooMailBasic@web28903.mail.ir2.yahoo.com> > 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 wrote: Subject: Re: [cdi-dev] Challenge TCK test for indirect specialization rules To: "Mark Struberg" , 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 From mkouba at redhat.com Wed Jun 4 02:43:17 2014 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 04 Jun 2014 08:43:17 +0200 Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <1401799360.48396.YahooMailBasic@web28903.mail.ir2.yahoo.com> References: <1401799360.48396.YahooMailBasic@web28903.mail.ir2.yahoo.com> Message-ID: <538EC005.7010000@redhat.com> 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 wrote: > > Subject: Re: [cdi-dev] Challenge TCK test for indirect specialization rules > To: "Mark Struberg" , 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 > From pmuir at redhat.com Wed Jun 4 09:10:31 2014 From: pmuir at redhat.com (Pete Muir) Date: Wed, 4 Jun 2014 14:10:31 +0100 Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <538EC005.7010000@redhat.com> References: <1401799360.48396.YahooMailBasic@web28903.mail.ir2.yahoo.com> <538EC005.7010000@redhat.com> Message-ID: 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 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 wrote: >> >> Subject: Re: [cdi-dev] Challenge TCK test for indirect specialization rules >> To: "Mark Struberg" , 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 From struberg at yahoo.de Wed Jun 4 12:13:03 2014 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 4 Jun 2014 17:13:03 +0100 (BST) Subject: [cdi-dev] dependent bean handling Message-ID: <1401898383.98630.YahooMailBasic@web28902.mail.ir2.yahoo.com> 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 stringBean = getBeans(String.class, TAME_LITERAL).iterator().next(); CreationalContext 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 From jharting at redhat.com Thu Jun 5 03:24:00 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 05 Jun 2014 09:24:00 +0200 Subject: [cdi-dev] dependent bean handling In-Reply-To: <1401898383.98630.YahooMailBasic@web28902.mail.ir2.yahoo.com> References: <1401898383.98630.YahooMailBasic@web28902.mail.ir2.yahoo.com> Message-ID: <53901B10.1020705@redhat.com> Agreed. This does not look right. On 06/04/2014 06:13 PM, Mark Struberg wrote: > 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 stringBean = getBeans(String.class, TAME_LITERAL).iterator().next(); > CreationalContext 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 > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From mkouba at redhat.com Thu Jun 5 04:21:04 2014 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 05 Jun 2014 10:21:04 +0200 Subject: [cdi-dev] dependent bean handling In-Reply-To: <53901B10.1020705@redhat.com> References: <1401898383.98630.YahooMailBasic@web28902.mail.ir2.yahoo.com> <53901B10.1020705@redhat.com> Message-ID: <53902870.6050602@redhat.com> Yep. By the way that's why we created a special util class org.jboss.cdi.tck.util.DependentInstance. This test is very old [1]. We should revise the whole test suite. I've created a new issue: https://issues.jboss.org/browse/CDITCK-424 Martin [1] https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/java/org/jboss/jsr299/tck/tests/implementation/producer/method/definition/ProducerMethodDefinitionTest.java#L72 Dne 5.6.2014 09:24, Jozef Hartinger napsal(a): > Agreed. This does not look right. > > On 06/04/2014 06:13 PM, Mark Struberg wrote: >> 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 stringBean = getBeans(String.class, TAME_LITERAL).iterator().next(); >> CreationalContext 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 >> >> _______________________________________________ >> 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 > From struberg at yahoo.de Thu Jun 5 17:16:28 2014 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 5 Jun 2014 22:16:28 +0100 (BST) Subject: [cdi-dev] arquillian version in the TCK Message-ID: <1402002988.16307.YahooMailBasic@web28901.mail.ir2.yahoo.com> Hi! the TCK obviously uses arquillian-1.1.2.Final. I did upgrade OWB itself to use 1.1.4.Final, but now pretty many TCK tests are broken. I already checked, and all the arquillian dependencies DO have the correct version imo. Any ideas? Liegrue, strub From mkouba at redhat.com Fri Jun 6 03:33:46 2014 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 06 Jun 2014 09:33:46 +0200 Subject: [cdi-dev] arquillian version in the TCK In-Reply-To: <1402002988.16307.YahooMailBasic@web28901.mail.ir2.yahoo.com> References: <1402002988.16307.YahooMailBasic@web28901.mail.ir2.yahoo.com> Message-ID: <53916EDA.3030705@redhat.com> Hi, 1.1.3.Final should work fine. As to 1.1.4.Final, I suspect ARQ-1733 (ShrinkWrap/Resolver upgrade). Tomas Remes will check this. Martin Dne 5.6.2014 23:16, Mark Struberg napsal(a): > Hi! > > the TCK obviously uses arquillian-1.1.2.Final. > > I did upgrade OWB itself to use 1.1.4.Final, but now pretty many TCK tests are broken. > I already checked, and all the arquillian dependencies DO have the correct version imo. > > Any ideas? > > Liegrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > From jharting at redhat.com Fri Jun 6 04:17:31 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 06 Jun 2014 10:17:31 +0200 Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <212784191.14555985.1401788921185.JavaMail.zimbra@redhat.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> <212784191.14555985.1401788921185.JavaMail.zimbra@redhat.com> Message-ID: <5391791B.9060308@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 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 From struberg at yahoo.de Fri Jun 6 05:10:10 2014 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 6 Jun 2014 10:10:10 +0100 (BST) Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <5391791B.9060308@redhat.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> <212784191.14555985.1401788921185.JavaMail.zimbra@redhat.com> <5391791B.9060308@redhat.com> Message-ID: <1402045810.7436.YahooMailNeo@web28904.mail.ir2.yahoo.com> 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. 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 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/b544c599/attachment-0001.html From jharting at redhat.com Fri Jun 6 05:33:16 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 06 Jun 2014 11:33:16 +0200 Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <1402045810.7436.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> <212784191.14555985.1401788921185.JavaMail.zimbra@redhat.com> <5391791B.9060308@redhat.com> <1402045810.7436.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: <53918ADC.3080508@redhat.com> 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 > 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 From issues at jboss.org Fri Jun 6 07:00:17 2014 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 6 Jun 2014 07:00:17 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-441) Enhance wording for indirect specialization in 4.3.1 In-Reply-To: References: Message-ID: Tomas Remes created CDI-441: ------------------------------- Summary: Enhance wording for indirect specialization in 4.3.1 Key: CDI-441 URL: https://issues.jboss.org/browse/CDI-441 Project: CDI Specification Issues Issue Type: Clarification Components: Inheritance and Specialization Affects Versions: 1.2.Final Reporter: Tomas Remes In the 4.3.1. Direct and indirect specialization is following: {quote} 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. {quote} It is not fully straightforward to deduce that the second point here is not just redundant first case, but rather transitive relationship in indirect specialization. Therefore I think the wording for indirect specialization should be enhanced. Explanation from Jozef is at http://lists.jboss.org/pipermail/cdi-dev/2014-June/005082.html. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From maabaffy at redhat.com Tue Jun 10 06:39:38 2014 From: maabaffy at redhat.com (Matus Abaffy) Date: Tue, 10 Jun 2014 06:39:38 -0400 (EDT) Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <5391791B.9060308@redhat.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> <212784191.14555985.1401788921185.JavaMail.zimbra@redhat.com> <5391791B.9060308@redhat.com> Message-ID: <1042534138.20701216.1402396778662.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jozef Hartinger" > To: "Matus Abaffy" , "Mark Struberg" > Cc: cdi-dev at lists.jboss.org > Sent: Friday, June 6, 2014 10:17:31 AM > Subject: Re: [cdi-dev] Challenge TCK test for indirect specialization rules > > > 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. Yes, of course, I am aware of these. I kind of misexpressed myself. What I wanted to say is that the indirect specialization is redundantly contained in "Then X will inherit the qualifiers and bean name of Y:". I think the following suffices: 'If X directly specializes Y, then X will inherit the qualifiers and bean name of Y:' >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 > From issues at jboss.org Thu Jun 12 07:09:37 2014 From: issues at jboss.org (Matus Abaffy (JIRA)) Date: Thu, 12 Jun 2014 07:09:37 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-442) Emphasize that decorators are not applied to the values of producers In-Reply-To: References: Message-ID: Matus Abaffy created CDI-442: -------------------------------- Summary: Emphasize that decorators are not applied to the values of producers Key: CDI-442 URL: https://issues.jboss.org/browse/CDI-442 Project: CDI Specification Issues Issue Type: Feature Request Components: Decorators Affects Versions: 1.2.Final Reporter: Matus Abaffy In Chapter _8. Decorators, it is mentioned that_ ??Decorators are not applied to the return value of a producer method or the current value of a producer field.?? \(1) However, in _8.1.2. Decorator delegate injection points_, it is stated that ??The decorator applies to beans that are assignable to the delegate injection point.?? \(2) I think that unless \(1) is moved somewhere after \(2), \(2) should be appended by "except for ..." to make it clear that the values of producers are not decorated. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From tremes at redhat.com Thu Jun 12 09:58:59 2014 From: tremes at redhat.com (Tomas Remes) Date: Thu, 12 Jun 2014 09:58:59 -0400 (EDT) Subject: [cdi-dev] arquillian version in the TCK In-Reply-To: <53916EDA.3030705@redhat.com> References: <1402002988.16307.YahooMailBasic@web28901.mail.ir2.yahoo.com> <53916EDA.3030705@redhat.com> Message-ID: <1296118985.34084459.1402581539275.JavaMail.zimbra@redhat.com> Hi Arquillian 1.1.3.Final brings shrinkwrap-descriptors in version 2.0.0-alpha-5, where org.jboss.shrinkwrap.descriptor.api.beans10.BeansDescriptor has been changed. Moreover there is https://issues.jboss.org/browse/ARQ-1758 in Arquillian 1.1.4.Final. Currently I can't see any reason to update. Tom ----- Original Message ----- From: "Martin Kouba" To: "Mark Struberg" , cdi-dev at lists.jboss.org Sent: Friday, June 6, 2014 9:33:46 AM Subject: Re: [cdi-dev] arquillian version in the TCK Hi, 1.1.3.Final should work fine. As to 1.1.4.Final, I suspect ARQ-1733 (ShrinkWrap/Resolver upgrade). Tomas Remes will check this. Martin Dne 5.6.2014 23:16, Mark Struberg napsal(a): > Hi! > > the TCK obviously uses arquillian-1.1.2.Final. > > I did upgrade OWB itself to use 1.1.4.Final, but now pretty many TCK tests are broken. > I already checked, and all the arquillian dependencies DO have the correct version imo. > > Any ideas? > > 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 -- Tomas Remes From struberg at yahoo.de Thu Jun 12 14:32:11 2014 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 12 Jun 2014 19:32:11 +0100 (BST) Subject: [cdi-dev] Challenge TCK test for indirect specialization rules In-Reply-To: <1042534138.20701216.1402396778662.JavaMail.zimbra@redhat.com> References: <1401784620.11843.YahooMailBasic@web28905.mail.ir2.yahoo.com> <212784191.14555985.1401788921185.JavaMail.zimbra@redhat.com> <5391791B.9060308@redhat.com> <1042534138.20701216.1402396778662.JavaMail.zimbra@redhat.com> Message-ID: <1402597931.79737.YahooMailNeo@web28904.mail.ir2.yahoo.com> And here we go doing a full cycle back to my initial statement. From what I (and Pete as well) do remember, the reason for 4.3.1 is that it should behave different to what Jozef says.? 4.3.1 is not unnecessary bollocks but is worded that way because the 'intermediate' specialized bean is INTENTIONALLY left out of the equation. This is why it is NOT unnecessary but indeed NEEDED and totally makes sense.? And if you look at Weld 1.x then you will see that old Weld versions did EXACTLY work that way as well.? LieGrue, strub On Tuesday, 10 June 2014, 12:39, Matus Abaffy wrote: > > > >----- Original Message ----- >> From: "Jozef Hartinger" >> To: "Matus Abaffy" , "Mark Struberg" >> Cc: cdi-dev at lists.jboss.org >> Sent: Friday, June 6, 2014 10:17:31 AM >> Subject: Re: [cdi-dev] Challenge TCK test for indirect specialization rules >> >> >> 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. > >Yes, of course, I am aware of these. I kind of misexpressed myself. >What I wanted to say is that the indirect specialization is redundantly >contained in "Then X will inherit the qualifiers and bean name of Y:". >I think the following suffices: >'If X directly specializes Y, then X will inherit the qualifiers and bean name of Y:' > > >>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/20140612/50667576/attachment.html From issues at jboss.org Tue Jun 17 07:35:25 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 17 Jun 2014 07:35:25 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-443) Clarify 10.4.1. Event parameter of an observer method In-Reply-To: References: Message-ID: Martin Kouba created CDI-443: -------------------------------- Summary: Clarify 10.4.1. Event parameter of an observer method Key: CDI-443 URL: https://issues.jboss.org/browse/CDI-443 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Martin Kouba 10.4.1. Event parameter of an observer method: {quote} If the event parameter does not explicitly declare any qualifier, the observer method observes events with no qualifier. {quote} 10.3. Observer resolution: {quote} An event is delivered to an observer method if: * ... * The observer method has no event qualifiers or has a subset of the event qualifiers. ... {quote} I find this quite confusing. The statement from 10.4.1 should be either removed or reworded. In fact, the observer method with no qualifier observes events with any qualifier. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 07:37:24 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 17 Jun 2014 07:37:24 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-443) Clarify "10.4.1. Event parameter of an observer method" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-443: ----------------------------- Summary: Clarify "10.4.1. Event parameter of an observer method" (was: Clarify 10.4.1. Event parameter of an observer method) > Clarify "10.4.1. Event parameter of an observer method" > ------------------------------------------------------- > > Key: CDI-443 > URL: https://issues.jboss.org/browse/CDI-443 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > 10.4.1. Event parameter of an observer method: > {quote} > If the event parameter does not explicitly declare any qualifier, the observer method observes events with no qualifier. > {quote} > 10.3. Observer resolution: > {quote} > An event is delivered to an observer method if: > * ... > * The observer method has no event qualifiers or has a subset of the event qualifiers. ... > {quote} > I find this quite confusing. The statement from 10.4.1 should be either removed or reworded. In fact, the observer method with no qualifier observes events with any qualifier. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From mkouba at redhat.com Mon Jun 23 03:35:12 2014 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 23 Jun 2014 09:35:12 +0200 Subject: [cdi-dev] CDI TCK - new releases, new lead Message-ID: <53A7D8B0.9090301@redhat.com> Hello everyone, we've just released three TCK bugfix releases: 1.2.1.Final 1.1.4.Final 1.0.6.Final The artifacts are available in the Maven central repository and the dist zip can be downloaded from sourceforge.net [1]. All the dist bundles contain updated sig files for the CDI API (jdk6, jdk7 and jdk8). Note that the canonical exclude lists were also updated [2]. Furthermore, CDI TCK gets a new lead - Tomas Remes (tremes at redhat.com). Tomas is a skilled JBoss Quality Assurance Engineer. He is experienced in CDI, Weld, Arquillian, WildFly and Java EE generally. Congratulations Tomas and good luck! Martin [1] https://sourceforge.net/projects/jboss/files/CDI-TCK [2] https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/resources/tck-tests.xml https://github.com/cdi-spec/cdi-tck/blob/1.1/impl/src/main/resources/tck-tests.xml https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/resources/tck-tests.xml -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Thu Jun 26 10:18:24 2014 From: issues at jboss.org (Matus Abaffy (JIRA)) Date: Thu, 26 Jun 2014 10:18:24 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-440) Clarify assignability rules for parameterized types with type variables with multiple bounds In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matus Abaffy updated CDI-440: ----------------------------- Description: Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds. For example, the bullet ??the required type parameter and the bean type parameter are both type variables and the upper bound of the required type parameter is assignable to the upper bound, if any, of the bean type parameter.?? should have meaning similar to: ... for each upper bound T of the bean type parameter, there is an (at least one) upper bound of the required type which is assignable to T. Consider the following example: \- interfaces Bar, Baz, Foo {code} class BarImpl implements Bar { ... } {code} {code} interface MyInterface { ... } {code} \- bean: {code} class MyBean implements MyInterface { ... } {code} \- injection point: {code} class TestClass { @Inject MyInterface bean; } {code} MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected. Please, correct me if I am wrong. was: Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds. For example, the bullet ??the required type parameter and the bean type parameter are both type variables and the upper bound of the required type parameter is assignable to the upper bound, if any, of the bean type parameter.?? should have meaning similar to: ... for each upper bound T of the bean type parameter, there is a (at least one) type variable of the required type which is assignable to T. Consider the following example: \- interfaces Bar, Baz, Foo {code} class BarImpl implements Bar { ... } {code} {code} interface MyInterface { ... } {code} \- bean: {code} class MyBean implements MyInterface { ... } {code} \- injection point: {code} class TestClass { @Inject MyInterface bean; } {code} MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected. Please, correct me if I am wrong. > Clarify assignability rules for parameterized types with type variables with multiple bounds > -------------------------------------------------------------------------------------------- > > Key: CDI-440 > URL: https://issues.jboss.org/browse/CDI-440 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Matus Abaffy > > Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds. > For example, the bullet > ??the required type parameter and the bean type parameter are both type variables and the upper bound of the required type parameter is assignable to the upper bound, if any, of the bean type parameter.?? > should have meaning similar to: > ... for each upper bound T of the bean type parameter, there is an (at least one) upper bound of the required type which is assignable to T. > Consider the following example: > \- interfaces Bar, Baz, Foo > {code} > class BarImpl implements Bar { ... } > {code} > {code} > interface MyInterface { ... } > {code} > \- bean: > {code} > class MyBean implements MyInterface { ... } > {code} > \- injection point: > {code} > class TestClass { > @Inject > MyInterface bean; > } > {code} > MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected. > Please, correct me if I am wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From jharting at redhat.com Mon Jun 30 03:30:27 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 30 Jun 2014 09:30:27 +0200 Subject: [cdi-dev] CDI TCK - new releases, new lead In-Reply-To: <53A7D8B0.9090301@redhat.com> References: <53A7D8B0.9090301@redhat.com> Message-ID: <53B11213.6020703@redhat.com> Congratulations Tomas! On 06/23/2014 09:35 AM, Martin Kouba wrote: > Hello everyone, > > we've just released three TCK bugfix releases: > 1.2.1.Final > 1.1.4.Final > 1.0.6.Final > > The artifacts are available in the Maven central repository and the dist > zip can be downloaded from sourceforge.net [1]. All the dist bundles > contain updated sig files for the CDI API (jdk6, jdk7 and jdk8). Note > that the canonical exclude lists were also updated [2]. > > Furthermore, CDI TCK gets a new lead - Tomas Remes (tremes at redhat.com). > Tomas is a skilled JBoss Quality Assurance Engineer. He is experienced > in CDI, Weld, Arquillian, WildFly and Java EE generally. Congratulations > Tomas and good luck! > > Martin > > [1] > https://sourceforge.net/projects/jboss/files/CDI-TCK > > [2] > https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/resources/tck-tests.xml > https://github.com/cdi-spec/cdi-tck/blob/1.1/impl/src/main/resources/tck-tests.xml > https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/resources/tck-tests.xml > From issues at jboss.org Mon Jun 30 07:09:23 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 30 Jun 2014 07:09:23 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-444) AnnotatedType should only returns visible methods In-Reply-To: References: Message-ID: Romain Manni-Bucau created CDI-444: -------------------------------------- Summary: AnnotatedType should only returns visible methods Key: CDI-444 URL: https://issues.jboss.org/browse/CDI-444 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Romain Manni-Bucau ATM spec says but actually it doesn't respect java inheritence rules which can induce some methods which are not callable or accessible to be present in AnnotatedType. (A test in TCKs does it if it is easier with a sample: org.jboss.cdi.tck.tests.extensions.beanManager.beanAttributes.CreateBeanAttributesTest#testBeanAttributesForMethod checks there are 2 methods "getFish" in the annotated type of org.jboss.cdi.tck.tests.extensions.beanManager.beanAttributes.Dam but Dam extends Lake overriding getFish so the Lake#getFish is totally hidden for Dam and shouldn't be tested and visible) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 30 09:05:24 2014 From: issues at jboss.org (Matus Abaffy (JIRA)) Date: Mon, 30 Jun 2014 09:05:24 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-445) Remove collocation 'if any' relating to upper bounds of wildcards and type variables In-Reply-To: References: Message-ID: Matus Abaffy created CDI-445: -------------------------------- Summary: Remove collocation 'if any' relating to upper bounds of wildcards and type variables Key: CDI-445 URL: https://issues.jboss.org/browse/CDI-445 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Matus Abaffy Priority: Minor These collocations are redundant: if there is no explicitly declared upper bound, the upper bound is Object. >From javadoc for TypeVariable#getBounds and WildcardType#getUpperBounds: "Note that if no upper bound is explicitly declared, the upper bound is Object." -- This message was sent by Atlassian JIRA (v6.2.6#6264)