[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-490:
-------------------------------------
Fix Version/s: 2.0 (proposed)
(was: 2.0 (discussion))
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-490:
------------------------------------------
During F2F we proposed choosing option 2).
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-490:
-------------------------------------
Labels: F2F2016 (was: )
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Labels: F2F2016
> Fix For: 2.0 (discussion)
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-471:
------------------------------------------
during F2F meeting we decided to support this feature
> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
> Key: CDI-471
> URL: https://issues.jboss.org/browse/CDI-471
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Reporter: Antonin Stefanutti
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
> String value;
> }
> public @interface ContextNames {
> ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-471:
-------------------------------------
Fix Version/s: 2.0 (proposed)
(was: 2.0 (discussion))
> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
> Key: CDI-471
> URL: https://issues.jboss.org/browse/CDI-471
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Reporter: Antonin Stefanutti
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
> String value;
> }
> public @interface ContextNames {
> ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand updated CDI-10:
------------------------------------
Labels: F2F2016 (was: )
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Labels: F2F2016
> Fix For: 2.0 (discussion)
>
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-224:
-------------------------------------
Labels: F2F2016 (was: )
> Support Decoration of no interface beans
> ----------------------------------------
>
> Key: CDI-224
> URL: https://issues.jboss.org/browse/CDI-224
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Aslak Knutsen
> Assignee: Antoine Sabot-Durand
> Labels: F2F2016
> Fix For: 2.0 (discussion)
>
>
> According to CDI 1.0 Spec:
> "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean."
> "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator."
> Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes.
> I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place.
> {code}
> import javax.decorator.Decorator;
> import javax.decorator.Delegate;
> import javax.enterprise.inject.Any;
> import javax.inject.Inject;
> import junit.framework.Assert;
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.jboss.shrinkwrap.impl.BeansXml;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(Arquillian.class)
> public class DecoratesClassTestCase {
> @Deployment
> public static WebArchive create() {
> return ShrinkWrap.create(WebArchive.class)
> .addAsWebInfResource(
> new BeansXml().decorators(BusinessDecorator.class), "beans.xml");
> }
>
> @Test
> public void shouldBeAbleToDecorate(BusinessObject business) throws Exception {
> Assert.assertEquals("Decorated Test", business.send("Test"));
> }
>
> @Decorator
> public static abstract class BusinessDecorator extends BusinessObject {
> @Inject @Delegate @Any
> private BusinessObject delegate;
>
> public String send(String msg) {
> return "Decorated " + delegate.send(msg);
> }
> }
>
> public static class BusinessObject {
>
> public String send(String msg) {
> return msg;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-527:
-------------------------------------
Labels: F2F2016 (was: )
> 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
> Labels: F2F2016
> 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)
7 years, 8 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-420:
-------------------------------------
Fix Version/s: 2.0 (proposed)
(was: 2.0 (discussion))
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-420:
-------------------------------------
Labels: F2F2016 (was: )
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months