[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-584 UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 30/May/17 3:14 PM Priority: Major Reporter: Mark Struberg UnproxyableManagedBeanTest assumes that only invocation of unproxyable beans at runtime lead to an UnproxyableResolutionException. But this clearly contradicts the specification (same wording since 1.0): See 3.11 Unproxyable Bean Types "Otherwise, the container automatically detects the problem, and treats it as a deployment problem." Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Tomas Remes commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Well the point is that there are no injection points for the given unproxyable types. So there is no need for injection point resolution to a bean as stated in 3.11 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. Otherwise, the container automatically detects the problem, and treats it as a deployment problem. I think the test is OK. 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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' That doesn't define that it's disallowed to detect those issues earlier - during deployment (as required by the spec). That test is illegal anyway. Because if we follow your interpretation then there is NO requirement for testing for unproxyable beans during runtime! The spec clearly only defines that the validation must happen during bootstrap - but no further behaviour at runtime is specified. 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 Tomas Remes commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Sorry but I don't agree. Actually I think there is the requirement to test unproxyable bean types during runtime (if there are no injection points for given types) and that's why UnproxyableResolutionException exists. The spec clearly only defines that the validation must happen during bootstrap - but no further behaviour at runtime is specified. I believe this is not true. Why would UnproxyableResolutionException (as defined in 6.5.4. Contextual reference for a bean) exist then? We should open CDI spec clarification issue once there is a disagreement. 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
Martin Kouba commented on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
The point is that theoretically you can have a similar bean:
interface Baz {
void ping();
}
@ApplicationScoped
class Foo implements Baz {}
public final String badMethod() {}; // Makes it unproxyable
public void ping() {};
}
This bean has bean types: Foo and Baz. However, the following use case should work:
class Service {
@Inject
Baz baz; // Inject client proxy for Foo bean instance
void doSomething() {
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Why would one then use @ApplicationScoped on a bean which is not intended to be used in CDI? That makes no sense at all to me. 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 Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Perhaps an integration with third-party/legacy library. 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 Tomas Remes commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Then it is the problem of the testsuite probably. Broken type which doesn't need to be resolved since it's not used. 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
Mark Struberg edited a comment on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
{quote} legacy libraries which contain CDI NormalScoped beans? {quote} C'mon ;)I give you another thing to think:You create a library jar which contains a few CDI Beans. They are intended to be used in other projects and by accident you do not touch them in your test suite.You will never figure that you have an actually broken bean. And yes, it's exactly that: a broken CDI bean!So now again please tell me where it's written that this detection must NOT be done already at startup?
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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' legacy libraries which contain CDI NormalScoped beans? C'mon I give you another thing to think: You create a library jar which contains a few CDI Beans. They are intended to be used in other projects and by accident you do not touch them in your test suite. You will never figure that you have an actually broken bean. And yes, it's exactly that: a broken CDI bean! So now again please tell me where it's written that this detection must NOT be done already at startup? 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-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Romain Manni-Bucau It is valid. The spec is clear that if you attempt to obtain a contextual reference for a bean that has a normal scope and the given bean type cannot be proxied you get an UnproxyableResolutionException, see also 6.5.4. Contextual reference for a bean. And the deployment should not fail if you don't use the bean at all. It might be inconsistent but this is what the spec states and was agreed by the EG. 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 Antoine Sabot-Durand commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Totally agree with Tomas Remes first comment, spec states in 3.11 A bean type must be proxyable if an injection point resolves to a bean: It implies that if there's no injection point, the bean type doesn't have to be proxyable. Tests exist for non proxyable bean detected at deployment, you can check all of them in the version of the spec with assertion: http://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#unproxyable UnproxyableManagedBeanTest relates to 6.5.4 where UnproxyableResolutionException is clearly stated: http://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#contextual_reference So for me this test is consistent with the spec. 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' 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 Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' I would be it is a very sane feature and consistent feature which means this test is not correct ... Wrong assumption. The TCK test must always follow the spec. not really cause if nothing prevents in the spec to fail at startup then the test should enable that as well. The fact, that the example above should work prevents such validation. It could be an impl-specific feature which has to be disabled when running the TCK though. 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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' +1 for Romains argument. Antoine Sabot-Durand your argument would be true with a "IF, AND ONLY IF" phrase. But since this is not there it is not required. And to be honest it also makes sense that way. The test scenario should trigger an error, right? And it triggers that error in Weld and OWB. But at some slightly different point in time. That's really all! Oh one more. If one would follow the strict interpretation, then the following should also NOT cause an Exception: @Inject Instance boomBaby; Because this is NOT an InjectionPoint of 'NonProxyableBean'. But that imo clearly should get detected at bootstrap time as well imo. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' ...so basically this test doesn't help validating the compliancy of the container. It does, because the example above should work in all containers. Also UnproxyableManagedBeanTest is testing assertions from 6.5.4. Contextual reference for a bean, namely UnproxyableResolutionException which is neither a definition error nor a deployment problem. 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 Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Because this is NOT an InjectionPoint of 'NonProxyableBean'. But that imo clearly should get detected at bootstrap time as well imo. This should not be detected. And what about all the Instance.select() occurences? This cannot be validated during bootstrap. Mark Struberg Romain Manni-Bucau Guys, it seems like we're stuck in cycles. From my point of view the spec is clear and an implementation should only validate existing injection points. Validating all the bean types is imho too "eager" and blocks certain functionality. Yet it might be useful in some use cases - an implementation can provide a non-portable feature. I think this issue should be rejected. Of course, it's up to the TCK lead. 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 Tomas Remes resolved as Rejected I am not going to repeat my reasoning why I think this test is OK. CDI spec lead shares same opinion with me so I can't see any reason why this test should be changed. CDI TCK / CDITCK-584 UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Change By: Tomas Remes Status: Open Resolved Resolution: Rejected 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/m
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg reopened an issue EG needs to clarify this. CDI TCK / CDITCK-584 UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Change By: Mark Struberg Resolution: Rejected Status: Resolved Reopened 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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Btw we have now changed our algorithm. It now parses the bytecode at boot time and detects BeanManager#getReferences and Instance#get and Select calls to those beans at startup. Would that be illegal? Doubt 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 Antoine Sabot-Durand commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Mark StrubergThis test has been in the TCK for 5 years now. It has been accepted as deliverable by the JCP in CDI 1.1 / 1.2MR and 2.0. Weld passes this test for CDI compliance, so it's possible to implement. The validity to his test doesn't have to be discussed here : you should expose your point to the future CDI 2.x EG. Spec is not designed from the TCK but the other way around, so, please, fill a ticket in CDI JIRA to ask for a clarification or a change in the spec for this non portable optimisation. 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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' No Antoine Sabot-Durand This is wrong! The test got changed because of WELD-1052 which was only Weld-2.x! Originally in CDI-1.0 it was REQUIRED to fail at boot time! The CDI-1.0 TCK did REQUIRE to fail at boot! That was the ORIGINAL behaviour and is still valid! Of course, one possible interpretation of the spec wording is that is not required to fail at boot. But it's also not forbidden! The current version of the test is just pinning down Weld specific behaviour and even contradicts JSR-299! 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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Oh, one more: If this rule is really that way since CDI-1.0, then please try to run that exact test with Weld-1.x^! You will see that it will blow up... 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 Mark Struberg edited a comment on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' No [~antoinesabot-durand] This is wrong!The test got changed because of WELD-1052 which was only Weld-2.x!Originally in CDI-1.0 it was REQUIRED to fail at boot time!The CDI-1.0 TCK did REQUIRE to fail at boot!That was the ORIGINAL behaviour and is still valid!Of course, one possible interpretation of the spec wording is that is not required to fail at boot. But it's also not forbidden!The current version of the test is just pinning down Weld specific behaviour and even contradicts JSR-299! Please check the revision history of this test! 576d4f5d2b489fa0ed76e 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 Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Originally in CDI-1.0 it was REQUIRED to fail at boot time! Not really. See below. The CDI-1.0 TCK did REQUIRE to fail at boot! Yes, it was a bug in TCK. Reported as CDITCK-263 and fixed in TCK 1.1. The current version of the test is just pinning down Weld specific behaviour and even contradicts JSR-299! What, why? CDI 1.0 wording is: "If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem." See also http://docs.jboss.org/cdi/spec/1.0/html/injectionelresolution.html#unproxyable. 6.5.3. Contextual reference for a bean is the same as well. You will see that it will blow up... Yes, the fix was not backported. See also https://issues.jboss.org/browse/WELD-1052?focusedCommentId=12709637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12709637 Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Antoine Sabot-Durand commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Mark StrubergI mentioned CDI 1.1, why are you talking about 1.0 ? The test is in CDI 1.1 TCK validated in 2013 by the CDI 1.1 EG and released to the JCP: https://github.com/cdi-spec/cdi-tck/blob/1.1/impl/src/main/java/org/jboss/cdi/tck/tests/implementation/simple/lifecycle/unproxyable/UnproxyableManagedBeanTest.java The Weld Ticket you mention is the middle of the story, the origin is CDITCK-263, closed 5 years ago with no comment. This test was enhanced in 2015 with other use case thru CDITCK-508, again no comment. I'm sorry you missed these occasion to discuss your point, but they are closed now and CDI 2.0 is released. You're assuming the original intent of the CDI 1.0 EG because of this test that was decided wrong later. I prefer to assume intent of the original EG to have these failing at runtime by reading the spec and the section related to UnproxyableResolutionException (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#contextual_reference). Again Spec supersede TCK and that's what happened with CDITCK-263. What you propose is interesting but non portable because the following behaviour was already adopted in RI, supported in vendors application servers and changing it could create backward compatibility issues. Again, I suggest that you propose a mention of this non portable behaviour in the spec. May I also suggest that you avoid putting exclamation marks and explaining people that they are wrong, It really doesn't help discussion. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Martin Kouba What, why? CDI 1.0 wording is: "If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem." But the test does NOT test this! The test does NOT have any Injection Point! The correct test to prove this section would be to have an unproxyable bean plus another Bean which injects this bean. And then verify that a deployment problem occurs! That's what this paragraph describes. But the current test checks for way more and implies behaviour which is not covered by the spec and even contradicts the CDI 1.0 TCK directly! 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 Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' But the test does NOT test this! The test does NOT have any Injection Point! Mark Struberg No. The test assertion is for the runtime exception - UnproxyableResolutionException. There is probably a different test for deployment error and injection point. Tomas Remes will know. 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 Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' I looked at the test again and afaict it was effectively disabled for 1.1 as it belonged to an unknown (and thus not enabled) testng Group. But let's take a step back and see what all the rules are for: 3.11 covers that any unproxyable bean which gets used in an InjectionPoint must lead to a deployment error. Both Weld and OWB behave correctly in that regard, right? 6.5.4 covers that any call to BeanManager#getReference must not hand out unproxyable beans. Weld does solve this by blowing up at the time a user calls this method, OWB solves this by detecting this situation even earlier. Both are perfectly spec compliant regarding 6.5.4 because they do not hand out unproxyable beans. What is left missing is the following cases: @Inject Instance instance; @Inject Provider provider; beanManager.getContext(RequestScoped.class).get(Contextual bean) And probably even more. Not sure what Weld does for them. OWB also detects these problems during bootstrap. Do you see anything where one of the containers contradict the spec from a user perspective? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-i
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' I looked at the test again and afaict it was effectively disabled for 1.1 as it belonged to an unknown (and thus not enabled) testng Group. Not true. Test groups are only used to exclude tests. The suite xml includes all tests by default. See for example TestGroups javadoc or RI TCK runner. Both Weld and OWB behave correctly in that regard, right? Yes. 6.5.4 covers that any call to BeanManager#getReference... I'm not going to repeat myself again. See my comment above. And probably even more. Not sure what Weld does for them. AFAIK Weld does not validate these cases during bootstrap. Do you see anything where one of the containers contradict the spec from a user perspective? A user might in theory rely on that the example above works on all containers. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title
Martin Kouba edited a comment on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
bq. I looked at the test again and afaict it was effectively disabled for 1.1 as it belonged to an unknown (and thus not enabled) testng Group.Not true. Test groups are only used to exclude tests - most tests do not specify the group . The suite xml includes all tests by default. See for example {{TestGroups}} javadoc or RI TCK runner.bq. Both Weld and OWB behave correctly in that regard, right?Yes.bq. 6.5.4 covers that any call to BeanManager#getReference...I'm not going to repeat myself again. See [my comment|https://issues.jboss.org/browse/CDITCK-584?focusedCommentId=13414386&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13414386] above.bq. And probably even more. Not sure what Weld does for them.AFAIK Weld does not validate these cases during bootstrap.bq. Do you see anything where one of the containers contradict the spec from a user perspective?A user might in theory rely on that the example above works on all containers.
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
Mark Struberg commented on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Martin Kouba Let's get back to your sample. I don't quite get it. You said one might be able to add another Bean implementing Baz and that would work? I cannot see how this should work, please help me to understand what you meant.
@ApplicationScoped
public class OtherFoo implements Baz { ..}
As far as I understand you would then get an AmbiguousResolutionException. The bean resolving algorithm doesn't care whether a Bean is proxyable or not. So you would end up with Bean and Bean for the InjectionPoint @Inject Baz baz; Or does Weld behave different in that case? Regarding my reference to Instance and Provider: Neither the atinject nor the CDI specification define that those methods return a 'Contextual Reference'. The CDI spec says in the Instance section: {qoute} The Instance interface provides a method for obtaining instances of beans..{qoute} Thus my question what Weld does. According to your interpretation a CDI container must not blow up with an UnproxyableResolutionExceptionthen because it's not specified. Again: I strongly believe that both Weld and OWB operate well within the intention and wording of the spec. What about using an Injected Arquillian deployer and check whether the UnproxyableResolutionException either gets thrown during bootstrap or during the actual use of this bean?
Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title
Mark Struberg edited a comment on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
[~mkouba] Let's get back to your sample. I don't quite get it.You said one might be able to add another Bean implementing Baz and that would work? I cannot see how this should work, please help me to understand what you meant.{code:java}@ApplicationScopedpublic class OtherFoo implements Baz { ..}{code}As far as I understand you would then get an AmbiguousResolutionException. The bean resolving algorithm doesn't care whether a Bean is proxyable or not. So you would end up with Bean and Bean for the InjectionPoint @Inject Baz baz; Or does Weld behave different in that case?Regarding my reference to Instance and Provider:Neither the atinject nor the CDI specification define that those methods return a 'Contextual Reference'.The CDI spec says in the Instance section:{ qoute quote }The Instance interface provides a method for obtaining instances of beans..{ qoute quote }Thus my question what Weld does. According to your interpretation a CDI container must not blow up with an UnproxyableResolutionExceptionthen because it's not specified. Again: I strongly believe that both Weld and OWB operate well within the intention and wording of the spec. What about using an Injected Arquillian deployer and check whether the UnproxyableResolutionException *either* gets thrown during bootstrap _or_ during the actual use of this bean?
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@list
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Martin Kouba commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' You said one might be able to add another Bean implementing Baz and that would work? Mark Struberg No, it should work as it is. @Inject Baz injects contextual reference (client proxy). "A contextual reference implements the given bean type and all bean types of the bean which are Java interfaces. A contextual reference is not, in general, required to implement all concrete bean types of the bean." (Contextual reference for a bean) So in this case, the client proxy only implements Baz and delegates to Foo contextual instance. I know it's a corner case. But it should work. What about using an Injected Arquillian deployer and check... Well, the problem is the test assertion (testing runtime behavior). I think the test must be either removed or left as it is. 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 Tomas Remes assigned an issue to Unassigned CDI TCK / CDITCK-584 UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Change By: Tomas Remes Assignee: Tomas Remes 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 Matej Novotny resolved as Rejected Resolving as Rejected. With my TCK lead hat on, I see this test as a correct one and supported by spec. So did former TCK lead and so does CDI spec lead. If you need to dispute this further, please raise a CDI spec issue instead and reformulate respective parts "more clearly" there which could then lead to this test being changed. CDI TCK / CDITCK-584 UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Change By: Matej Novotny Status: Reopened Resolved Resolution: Rejected Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849)
