[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-527:
----------------------------------------
Think D is just not realistic enough to be reliable on the long term (+ better is the spec doesnt get 100 pages of whitelist/blackist ;))
C sounds overkill for this particular and precise need
I hesitate between A and B cause B gives the ability to just code "java" which is nice. Now I never saw an application seeing this as a real issue/blocker (means when it happens the reaction is: "ah? not allowed, ok let's do this other way") so A would work fine with a very low cost.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
I wrote down a summary of the problem and possible solutions for proxying with final fields:
Java8 introduced a few final methods to existing classes.
This now leads to a javax.enterprise.inject.UnproxyableResolutionException at bootstrap if you have a producer method or field for those classes.
EJB also seemingly allows this.
But it's specced on a completely different level.
EJB disallows final 'business methods'.
That means that whenever you have an interface only those methods will get proxied.
The methods of the implementation do not matter at all.
With NIV all methods are 'business methods' and must be proxyable imo (can someone verify this?).
I personally like the non-proxyable rule.
It really prevents tons o user errors.
As you all know CDI heavily relies on subclassing proxies.
Means we override all methods from the proxied type.
But we obviously cannot override (and thus proxy) static, private and final methods.
While static and private methods do not really matter, all non-private non-static final methods do.
The problem appears when people invoke such a final method on the proxy.
In that case they will just hit the proxy and not the Contextual Instance.
To prevent the user from making this error we throw the UnproxyableResolutionException at bootstrap.
We now have a few options to deal with that:
A.) no it's not a problem at all.
- We often got the report for ConcurrentHashMap.
But people can already just use the ConcurrentMap interface as return type in their producers.
- Also the report that this only makes a problem since Java8 is plain wrong imo.
ConcurrentHashMap has the following method since at least Java7:
final V put(K key, int hash, V value, boolean onlyIfAbsent)
- There are a few situations where it hurts though.
E.g. extending ConcurrentHashMap with own functionality.
This would require introducing an own interface for this new functionality.
B.) Generally allow proxying of beans with final methods.
- I'm rather -1 for this.
The current behaviour was introduced exactly because people made too many errors and blew up at runtime.
Removing this rule would really make things worse.
Because people might then add new final methods.
And if you call those then you will only hit the proxy class and not the Contextual Instance.
C.) Introduce an annotation to explicitly declare Beans to be proxyable
- Something like @AllowProxying
Can be applied to producer methods, producer fields and managed beans.
- That would make it explicit for programmers that they leave the sunshine path.
People will blow up with the UnproxyableResolutionException and can then decide whether they want to provide that bean anyway or not.
- Con: Only the author of the Producer or managed bean knows that he added it.
Thus other users will first need to look at the producer to become aware.
But that might not be so much of a problem in most cases as it's only a matter of JavaDoc.
D.) Introduce an exclude list for knowingly 'bad' classes.
- We could e.g. introduce that all classes from java.* and javax.* are proxyable by definition.
- Con: hard to know what's going on and why the code doesn't work if a user calls such a final method.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
Canceling meeting
by Antoine Sabot-Durand
Hi guys,
I have. a personals emergency and have to leave. So he meeting today.
Antoine
8 years, 4 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-574 at 12/1/15 2:37 AM:
-----------------------------------------------------------
Yes, on Weld the deployment fails with unsatisfied dependencies - see also the original description.
was (Author: mkouba):
Yes, application deployment fails with unsatisfied dependencies - see also the original description.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-574:
----------------------------------
Yes, application deployment fails with unsatisfied dependencies - see also the original description.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
