[
https://issues.jboss.org/browse/CDI-739?page=com.atlassian.jira.plugin.sy...
]
Frigo Coder commented on CDI-739:
---------------------------------
Correctness and safety is more important than performance in my opinion. An optional check
would be nice if a universally enforced solution is not feasible. What do you mean it
would fail for cases with Instance? Instance<String> works perfectly and is in fact
my current workaround. Do you mean dynamically or manually created beans?
If I understand correctly this check is something I could do by myself using CDI
extensions? Subscribe to lifecycle events, get hold of InjectionPoint or something, verify
that injected bean is proxyable or the scopes are compatible, otherwise throw a big ass
DeploymentException. I could handle simple cases directly like injecting a String, whereas
I could use reflection and recursion to verify the entire network of beans is correct.
Scope mismatch can lead to subtle bugs
--------------------------------------
Key: CDI-739
URL:
https://issues.jboss.org/browse/CDI-739
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans, Contexts, Java EE integration
Environment: IBM WebSphere Liberty, Java EE 7.0 Full Platform
Reporter: Frigo Coder
Priority: Major
CDI allows injection of a non-proxyable object created by a provider into higher level
contextes. This can lead to subtle bugs, see the following example, the first username
that accesses the service is returned for other users:
{code:java}
@ApplicationScoped
public class ServiceClass {
@Inject
@UserName
private String userName;
}
@RequestScoped
public class UserNameProvider {
@Inject
private HttpServletRequest request;
@Produces
@UserName
public String userName() {
return request.getUserPrincipal().getName();
}
}
{code}
CDI should fail to start when it detects such a situation. Do note that this bug does not
require direct injection (Service->userName), it can occur transitively as well
(Service->User->userName).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)