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. |