[JBoss JIRA] (CDI-740) Proxy fields can be accessed if they are protected or package private
by Martin Kouba (Jira)
[ https://issues.jboss.org/browse/CDI-740?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-740:
----------------------------------
bq. Data classes with public fields would make sense.
I think that data classes are not supposed to be CDI beans whose lifecycle is managed by the container.
Anyway, if you disallow protected fields you will limit the possibilities of class hierarchies a lot.
I can't think of any practical reason for package-private fields though. Which of course does not mean there isn't any ;-)
> Proxy fields can be accessed if they are protected or package private
> ---------------------------------------------------------------------
>
> Key: CDI-740
> URL: https://issues.jboss.org/browse/CDI-740
> 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 detects and rejects proxyable beans if they expose a public field. However protected and package private fields are silently accepted. In the following example the method returns 0 instead of the correct value of 8:
> {code:java}
> @ApplicationScoped
> public class Car {
> @Inject
> private Engine engine;
> public int numberOfEngineCylinders() {
> return engine.cylinders;
> }
> }
> @RequestScoped
> public class Engine {
> protected int cylinders;
> @PostConstruct
> public void init() {
> cylinders = 8;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (CDI-740) Proxy fields can be accessed if they are protected or package private
by Frigo Coder (Jira)
[ https://issues.jboss.org/browse/CDI-740?page=com.atlassian.jira.plugin.sy... ]
Frigo Coder edited comment on CDI-740 at 12/3/18 12:08 PM:
-----------------------------------------------------------
{quote}Does it even make sense to ask this? Accessing fields directly is undesirable as a (java) practice in the first place...{quote}
Data classes with public fields would make sense. Protected and package private fields make much less sense, I still managed to trip myself up with them, can not remember the exact situation though. I sometimes wish Java had properties instead of fields so that proxying would work seamlessly.
{quote}Anyway, I have no idea if it was intentional back when it was specified this way but adjusting it now will cause backward compat. problems as now working applications would suddenly crash during bootstrap.{quote}
Fair point, thank you for at least considering it. I think I will still try to create a CDI extension to check for these cases in our project, I would like to be certain and we have no such compatibility issues.
was (Author: frigocoder):
> Does it even make sense to ask this? Accessing fields directly is undesirable as a (java) practice in the first place...
Data classes with public fields would make sense. Protected and package private fields make much less sense, I still managed to trip myself up with them, can not remember the exact situation though. I sometimes wish Java had properties instead of fields so that proxying would work seamlessly.
> Anyway, I have no idea if it was intentional back when it was specified this way but adjusting it now will cause backward compat. problems as now working applications would suddenly crash during bootstrap.
Fair point, thank you for at least considering it. I think I will still try to create a CDI extension to check for these cases in our project, I would like to be certain and we have no such compatibility issues.
> Proxy fields can be accessed if they are protected or package private
> ---------------------------------------------------------------------
>
> Key: CDI-740
> URL: https://issues.jboss.org/browse/CDI-740
> 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 detects and rejects proxyable beans if they expose a public field. However protected and package private fields are silently accepted. In the following example the method returns 0 instead of the correct value of 8:
> {code:java}
> @ApplicationScoped
> public class Car {
> @Inject
> private Engine engine;
> public int numberOfEngineCylinders() {
> return engine.cylinders;
> }
> }
> @RequestScoped
> public class Engine {
> protected int cylinders;
> @PostConstruct
> public void init() {
> cylinders = 8;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (CDI-740) Proxy fields can be accessed if they are protected or package private
by Frigo Coder (Jira)
[ https://issues.jboss.org/browse/CDI-740?page=com.atlassian.jira.plugin.sy... ]
Frigo Coder commented on CDI-740:
---------------------------------
> Does it even make sense to ask this? Accessing fields directly is undesirable as a (java) practice in the first place...
Data classes with public fields would make sense. Protected and package private fields make much less sense, I still managed to trip myself up with them, can not remember the exact situation though. I sometimes wish Java had properties instead of fields so that proxying would work seamlessly.
> Anyway, I have no idea if it was intentional back when it was specified this way but adjusting it now will cause backward compat. problems as now working applications would suddenly crash during bootstrap.
Fair point, thank you for at least considering it. I think I will still try to create a CDI extension to check for these cases in our project, I would like to be certain and we have no such compatibility issues.
> Proxy fields can be accessed if they are protected or package private
> ---------------------------------------------------------------------
>
> Key: CDI-740
> URL: https://issues.jboss.org/browse/CDI-740
> 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 detects and rejects proxyable beans if they expose a public field. However protected and package private fields are silently accepted. In the following example the method returns 0 instead of the correct value of 8:
> {code:java}
> @ApplicationScoped
> public class Car {
> @Inject
> private Engine engine;
> public int numberOfEngineCylinders() {
> return engine.cylinders;
> }
> }
> @RequestScoped
> public class Engine {
> protected int cylinders;
> @PostConstruct
> public void init() {
> cylinders = 8;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (CDI-739) Scope mismatch can lead to subtle bugs
by Frigo Coder (Jira)
[ 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)
6 years
[JBoss JIRA] (CDI-740) Proxy fields can be accessed if they are protected or package private
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/CDI-740?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-740:
-----------------------------------
bq. Is this intentional, are there any valid uses cases for them, or is it just an oversight?
Does it even make sense to ask this? Accessing fields directly is undesirable as a (java) practice in the first place...
Anyway, I have no idea if it was intentional back when it was specified this way but adjusting it now will cause backward compat. problems as now working applications would suddenly crash during bootstrap.
> Proxy fields can be accessed if they are protected or package private
> ---------------------------------------------------------------------
>
> Key: CDI-740
> URL: https://issues.jboss.org/browse/CDI-740
> 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 detects and rejects proxyable beans if they expose a public field. However protected and package private fields are silently accepted. In the following example the method returns 0 instead of the correct value of 8:
> {code:java}
> @ApplicationScoped
> public class Car {
> @Inject
> private Engine engine;
> public int numberOfEngineCylinders() {
> return engine.cylinders;
> }
> }
> @RequestScoped
> public class Engine {
> protected int cylinders;
> @PostConstruct
> public void init() {
> cylinders = 8;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years
[JBoss JIRA] (CDI-740) Proxy fields can be accessed if they are protected or package private
by Frigo Coder (Jira)
[ https://issues.jboss.org/browse/CDI-740?page=com.atlassian.jira.plugin.sy... ]
Frigo Coder commented on CDI-740:
---------------------------------
I do recognize that we are accessing an uninitialized field of a proxy object. Weld does refuse to start if the field in question is public. But not for protected and package private fields, they are silently ignored. Is this intentional, are there any valid uses cases for them, or is it just an oversight?
> Proxy fields can be accessed if they are protected or package private
> ---------------------------------------------------------------------
>
> Key: CDI-740
> URL: https://issues.jboss.org/browse/CDI-740
> 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 detects and rejects proxyable beans if they expose a public field. However protected and package private fields are silently accepted. In the following example the method returns 0 instead of the correct value of 8:
> {code:java}
> @ApplicationScoped
> public class Car {
> @Inject
> private Engine engine;
> public int numberOfEngineCylinders() {
> return engine.cylinders;
> }
> }
> @RequestScoped
> public class Engine {
> protected int cylinders;
> @PostConstruct
> public void init() {
> cylinders = 8;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years