[weld-issues] [JBoss JIRA] (CDITCK-441) Some interceptors are not valid.
Title: Message Title Tomas Remes created an issue CDI TCK / CDITCK-441 Some interceptors are not valid. Issue Type: Bug Affects Versions: 1.2.1.Final Assignee: Tomas Remes Created: 11/Sep/14 3:59 AM Fix Versions: 2.0.0.Alpha1, 1.2.2.Final Priority: Major Reporter: Tomas Remes According the Interceptors spec: An interceptor class must not be abstract and must have a public no-arg constructor. We have few interceptors in TCK, which don't satisfy this rule e.g: AnimalInterceptor CatInterceptor AlmightyLifecycleInterceptor SheepInterceptor PublicLifecycleInterceptor Add
[weld-issues] [JBoss JIRA] (CDITCK-442) Cover some missing assertions for 2.2.1 Legal bean types spec chapter
Title: Message Title Tomas Remes created an issue CDI TCK / CDITCK-442 Cover some missing assertions for 2.2.1 Legal bean types spec chapter Issue Type: Task Assignee: Tomas Remes Created: 11/Sep/14 4:24 AM Fix Versions: 2.0.0.Alpha1 Priority: Major Reporter: Tomas Remes There is missing test in TCK for following spec assertion: However, some Java types are not legal bean types : ... An array type whose component type is not a legal bean type. These are assertions lc and ld in 2.2.1 in current TCK audit. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-442) Cover some missing assertions for 2.2.1 Legal bean types spec chapter
Title: Message Title Tomas Remes assigned an issue to Kirill Gaevskii CDI TCK / CDITCK-442 Cover some missing assertions for 2.2.1 Legal bean types spec chapter Change By: Tomas Remes Assignee: TomasRemes KirillGaevskii Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-439) YoghurtConstructor and other normalscoped classes miss a default ct
Title: Message Title Martin Kouba commented on CDITCK-439 Re: YoghurtConstructor and other normalscoped classes miss a default ct For the record, these tests do not work on Weld only by accident. Weld does not treat it as a deployment problem because it's not required by the spec. See also 3.15. Unproxyable bean types: A bean type must be proxyable if an injection point resolves to a bean: that requires a client proxy, or that has an associated decorator, or that has a bound interceptor. And there's no injection point which resolves to the YoghurtConstructor. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-439) YoghurtConstructor and other normalscoped classes miss a default ct
Title: Message Title Mark Struberg commented on CDITCK-439 Re: YoghurtConstructor and other normalscoped classes miss a default ct I did re-read it as I could not believe it - but it seems you are right. So this is not a bug in Weld if it doesn't detect this programming error. For the record: if you write a @RequestScoped bean without a default ct, then you cannot use it. Not via @Inject, nor via @EJB nor via BeanManager#getReference, Provider or Instance... It would just trash at runtime. Imo this is a clear programming error from the user. Please note that the spec defines in which cases the container must detect a problem - but it doesn't say that other cases must work. In OWB we just detect those cases as bugs as well. This is of course not required, but also not forbidden. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-439) YoghurtConstructor and other normalscoped classes miss a default ct
Title: Message Title Martin Kouba commented on CDITCK-439 Re: YoghurtConstructor and other normalscoped classes miss a default ct For the record: if you write a @RequestScoped bean without a default ct, then you cannot use it. Not via @Inject, nor via @EJB nor via BeanManager#getReference, Provider or Instance... It would just trash at runtime. Imo this is a clear programming error from the user. Theoretically you can use a contextual instance obtained by Context.get(). But yes, it does not make much sense. Please note that the spec defines in which cases the container must detect a problem - but it doesn't say that other cases must work. In OWB we just detect those cases as bugs as well. This is of course not required, but also not forbidden. Yes, that's why we fixed the test Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-443) Some WS related tests failing on WildFly 9- SNAPSHOT
Title: Message Title Tomas Remes created an issue CDI TCK / CDITCK-443 Some WS related tests failing on WildFly 9- SNAPSHOT Issue Type: Enhancement Affects Versions: 1.2.1.Final Assignee: Tomas Remes Created: 11/Sep/14 9:28 AM Environment: WildFly 9.0.0.Alpha1-SNAPSHOT f99a6611acc1841f5f68120ff417318beef62dd5 Fix Versions: 2.0.0.Alpha1, 1.2.2.Final Priority: Major Reporter: Tomas Remes Following tests fail: WebServiceResourceStaticProducerFieldTest WebServiceResourceTest WebServiceResourceInjectionTest The first fails with: java.lang.AssertionError: expected object to not be null at org.testng.Assert.fail(Assert.java:89) at org.testng.Assert.assertNotNull(Assert.java:399) at org.testng.Assert.assertNotNull(Assert.java:384) at
