[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'

Mark Struberg (JIRA) Fri, 02 Jun 2017 07:42:00 -0700

Title: Message Title

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<Foo> and Bean<OtherFoo> for the InjectionPoint @Inject Baz baz;
Or does Weld behave different in that case?

Regarding my reference to Instance<T> and Provider<T>:
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

This message was sent by Atlassian JIRA

_______________________________________________
weld-issues mailing list
[email protected]
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'

Reply via email to