[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Matěj Novotný oki, thanks for the clarification on the version. Ok also it is written in the spec but also ok it is wrong so should be fixed, opened https://issues.redhat.com/browse/CDI-746. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Matěj Novotný CDI 2.0.1 does NOT exist, it is a binary version, not a spec fix so it looks ackward, nothing more. If you wrap instances it is fine but since PIP is also used to capture injections and beans to add in ABD then you break the container enabling to veto after. All vetos should only be doable before advanced introspection otherwise extensions are very complex to write - not a single one out there works with this paradigm btw, even in DS/MP lands. It also makes extensions + alternatives/specialization quite weirdly behaving so I think veto should be in the first phases then shouldn't be at all. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Matěj Novotný hmm, nowhere it is written that the bullet order must be respected so it is not in the spec IMO. Then on a functional sense, it is a non-sense to fire PBA after PIP and PIT. PBA is way closer to PAT by the operation it defines and a veto BA must not lead to PIP or PIT so should be just after PAT by design - but I agree it is not explicitly specified today so means PBA before is straight forward for users, PBA after requires extensions to revise the PIT and PIP capture after the whole discovery to be accurate (which is quite complex for nothing IMHO). Not directly linked to this issue but since you mention it: is 2.0.1.Final anything in terms of spec (I can see what it is in terms of artifact release but not spec)? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Hi, Can it be revised? Spec lists the needed events but it is not written the order must be this one + it is more logical to add PBA at the beginning, next to PAT since it has veto data, does not make sense to do it at the end cause it is already too late. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Antoine Sabot-Durand this is interesting cause your point can be taken both ways mainly cause weld and OWB for historical reasons didn't take the same path on that topic. So you have app servers in both "camps". So concretely I think the outcome is that the spec doesnt cover startup expectations there and therefore the behavior is not portable (but still valid) and therefore 2.1 (or "2.0 +1 ") should clarify it and probably enable to implement it this way to not break tons of applications and keep the goodness several users like (strong startup validations). I'm not sure how to treat this test since I get the fact the spec writes that if the validation is not done at startup it should behave this way but if the validation is done at startup the test can't pass in its current form. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Antoine Sabot-Durand well this is not really about the spec there but the way the test is written. It is valid to enforce more than the spec and therefore this test should accept the validation is done at startup. If it is a matter of submitting a patch to the tck suite i'm sure Mark or me can help on that. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Well being said the spec doesn't mention it shouldnt fail at startup and that EE as a whole (CDI included) tries to validate as much as possible at startup I think it should be excluded. On the "blocks" some use cases you can keep in mind that they are not blocked cause you can still veto the bean and add them with the proxy factory if you really want that but at least cdi boot validations are consistent if it doesn't lazy fail. Of course we can't detect all cases but we should at least ensure we can detect the trivial ones like the one mentionned here which are the most common. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Martin Kouba no, if you handle it as a deployment error - which is allowed by the spec - then UnproxyableResolutionException is not needed but the spec doesnt requires it so this test is really testing a particular case of weld. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Yes we are in a undirectional condition. "If you pass the test you are compliant" but "if you don't pass the test you can still be compliant" so basically this test doesn't help validating the compliancy of the container so it should either be rewritten to handle deployment errors corresponding to this case (using arquillian deployer for instance which would enable to catch up both cases) or it should be excluded IMHO. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Antoine Sabot-Durand not really cause if nothing prevents in the spec to fail at startup then the test should enable that as well. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Martin Kouba can you point me to the part of the spec preventing the deployment error? I would be it is a very sane feature and consistent feature which means this test is not correct (cause it assumes it is not the case but being the case covers the spec requirements). Also if the bean is not used is not limited to injection points as mentionned so it means the test is still weld dependent from what I understood. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Romain Manni-Bucau commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Hmm, not sure your example is valid Martin Kouba cause Foo MUST be proxyable since you can get a reference on it even if not in an injectable point so deployment should fail whatever way you think (getReference is part of CDI api ). So I think I agree with Mark and this test is a particular case limiting CDI and delaying user errors at runtime which is kind of inconsistent with deployment validations. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-463) org.jboss.cdi.tck.tests.lookup.manager.provider.custom.TestCDI relies on configuredProvider which is not portable
Title: Message Title Romain Manni-Bucau commented on CDITCK-463 Re: org.jboss.cdi.tck.tests.lookup.manager.provider.custom.TestCDI relies on configuredProvider which is not portable One or two IIRC, will surely meet them again when I'll get more time to work on it. BTW alternative can be to add a SPI to TCKs CDIProviderResetter - name is bad but you get the idea . Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-463) org.jboss.cdi.tck.tests.lookup.manager.provider.custom.TestCDI relies on configuredProvider which is not portable
Title: Message Title Romain Manni-Bucau created an issue CDI TCK / CDITCK-463 org.jboss.cdi.tck.tests.lookup.manager.provider.custom.TestCDI relies on configuredProvider which is not portable Issue Type: Feature Request Assignee: Tomas Remes Created: 11/Jan/15 1:41 PM Priority: Major Reporter: Romain Manni-Bucau Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-463) org.jboss.cdi.tck.tests.lookup.manager.provider.custom.TestCDI relies on configuredProvider which is not portable
Title: Message Title Romain Manni-Bucau commented on CDITCK-463 Re: org.jboss.cdi.tck.tests.lookup.manager.provider.custom.TestCDI relies on configuredProvider which is not portable Tomas Remes yes, sorry of the brief description. 1) I didnt find any reference to this field in the spec - did I miss it? 2) geronimo spec jar doesnt use it ( https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jcdi_1.1_spec/src/main/java/javax/enterprise/inject/spi/CDI.java ) Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-460) move org.jboss.cdi.tck.tests.extensions.lifecycle.atd.AfterTypeDiscoveryTest
Title: Message Title Romain Manni-Bucau created an issue CDI TCK / CDITCK-460 move org.jboss.cdi.tck.tests.extensions.lifecycle.atd.AfterTypeDiscoveryTest Issue Type: Feature Request Assignee: Tomas Remes Created: 20/Dec/14 5:45 AM Priority: Major Reporter: Romain Manni-Bucau org.jboss.cdi.tck.tests.extensions.lifecycle.atd.AfterTypeDiscoveryTest is only CDI so why is it in groups INTEGRATION? Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29)
