From issues at jboss.org Mon Nov 2 06:15:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Nov 2015 06:15:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-558: ------------------------------------- Summary: Standardize the Meta-Data builders API (BeanBuilder, etc...) (was: Standardize the BeanBuilder API) > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 2 09:17:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Nov 2015 09:17:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-558: ------------------------------------- Fix Version/s: 2.0 (discussion) > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 2 09:34:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Nov 2015 09:34:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124307#comment-13124307 ] Antoine Sabot-Durand commented on CDI-558: ------------------------------------------ We should do this for all SPI metadata in the spec. That would bring us: * {{AnnotatedTypeBuilder}} * {{BeanAttributesBuilder}} (Ancestor of BeanBuilder to be used in ProcessBeanAttributes) * {{InjectionPointBuilder}} * {{ObserverMethodBuilder}} Less sure about: * {{InjectionTargetBuilder}} (we already have a factory) * {{ProducerBuilder}} (Factory here as well) The question is how should we retrieve these builders. I don't think it's a good idea to restrict their access to lifecyle event since we could need them outside an extension. {{BeanManager}} seems the obvious place but there are already too much method in it. Perhaps it's time to create an interface for such service method, that the BeanManager would implement and that could be injected as well to provide access to these builders. WDYT ? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 2 09:44:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Nov 2015 09:44:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-484) Provide forwarding implementations of SPI interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124312#comment-13124312 ] Antoine Sabot-Durand commented on CDI-484: ------------------------------------------ I think we could merge with feature with CDI-558. Decorating an existing metadata could be done with a read() method taking the metadata type. > Provide forwarding implementations of SPI interfaces > ---------------------------------------------------- > > Key: CDI-484 > URL: https://issues.jboss.org/browse/CDI-484 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > The decorator design pattern is commonly used in CDI extensions to modify existing metadata by wrapping it with a wrapper implementation that overrides certain method. This can be done in the following callbacks: ProcessAnnotatedType, ProcessProducer, ProcessInjectionTarget, ProcessInjectionPoint and ProcessBeanAttributes. > In order to do this it is often very convenient to have a forwarding implementation available, e.g.: > {code:JAVA} > void wrap(@Observes ProcessAnnotatedType event) { > final AnnotatedType delegate = event.getAnnotatedType(); > event.setAnnotatedType(new ForwardingAnnotatedType(delegate) { > @Override > public A getAnnotation(Class annotationType) { > return null; > } > @Override > public Set getAnnotations() { > return Collections.emptySet(); > } > @Override > public boolean isAnnotationPresent(Class annotationType) { > return false; > } > } > {code} > We should consider providing these utility forwarding implementations as part of the CDI API. This is similar to e.g. Servlet specification doing this for their decorable APIs (http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequestWrapper.html) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 2 09:45:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Nov 2015 09:45:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-484) Provide forwarding implementations of SPI interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124313#comment-13124313 ] Antoine Sabot-Durand commented on CDI-484: ------------------------------------------ it's a sub use case of building metadata. > Provide forwarding implementations of SPI interfaces > ---------------------------------------------------- > > Key: CDI-484 > URL: https://issues.jboss.org/browse/CDI-484 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > The decorator design pattern is commonly used in CDI extensions to modify existing metadata by wrapping it with a wrapper implementation that overrides certain method. This can be done in the following callbacks: ProcessAnnotatedType, ProcessProducer, ProcessInjectionTarget, ProcessInjectionPoint and ProcessBeanAttributes. > In order to do this it is often very convenient to have a forwarding implementation available, e.g.: > {code:JAVA} > void wrap(@Observes ProcessAnnotatedType event) { > final AnnotatedType delegate = event.getAnnotatedType(); > event.setAnnotatedType(new ForwardingAnnotatedType(delegate) { > @Override > public A getAnnotation(Class annotationType) { > return null; > } > @Override > public Set getAnnotations() { > return Collections.emptySet(); > } > @Override > public boolean isAnnotationPresent(Class annotationType) { > return false; > } > } > {code} > We should consider providing these utility forwarding implementations as part of the CDI API. This is similar to e.g. Servlet specification doing this for their decorable APIs (http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequestWrapper.html) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 2 09:51:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 2 Nov 2015 09:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124318#comment-13124318 ] Martin Kouba commented on CDI-558: ---------------------------------- bq. The question is how should we retrieve these builders For {{BeanBuilder}}, {{BeanAttributesBuilder}} and {{ObserverMethodBuilder}} I think it is a good idea to restrict the access to container lifecycle events (or [CDI SE builder|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java#L488] respectivelly). Maybe we should create a table and for each SPI add some description, purpose and/or use-case, possible implementation problems, etc. > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 2 10:00:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 2 Nov 2015 10:00:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-484) Provide forwarding implementations of SPI interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124323#comment-13124323 ] Martin Kouba commented on CDI-484: ---------------------------------- I don't think it's the same. {{ForwardingImplementation}} is more like a decorator pattern - subclasses override one or more methods to modify the behavior. If you look at the example in the description - the annotated type from the event is decorated. And this annotated type could have been modified by any other extension (!) - this cannot be implemented by a builder read method. Therefore, I believe we should add these forwarding implementations. > Provide forwarding implementations of SPI interfaces > ---------------------------------------------------- > > Key: CDI-484 > URL: https://issues.jboss.org/browse/CDI-484 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > The decorator design pattern is commonly used in CDI extensions to modify existing metadata by wrapping it with a wrapper implementation that overrides certain method. This can be done in the following callbacks: ProcessAnnotatedType, ProcessProducer, ProcessInjectionTarget, ProcessInjectionPoint and ProcessBeanAttributes. > In order to do this it is often very convenient to have a forwarding implementation available, e.g.: > {code:JAVA} > void wrap(@Observes ProcessAnnotatedType event) { > final AnnotatedType delegate = event.getAnnotatedType(); > event.setAnnotatedType(new ForwardingAnnotatedType(delegate) { > @Override > public A getAnnotation(Class annotationType) { > return null; > } > @Override > public Set getAnnotations() { > return Collections.emptySet(); > } > @Override > public boolean isAnnotationPresent(Class annotationType) { > return false; > } > } > {code} > We should consider providing these utility forwarding implementations as part of the CDI API. This is similar to e.g. Servlet specification doing this for their decorable APIs (http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequestWrapper.html) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 2 10:32:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Nov 2015 10:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-568: ---------------------------------------- Summary: Enhancing Java SE bootstrap API Key: CDI-568 URL: https://issues.jboss.org/browse/CDI-568 Project: CDI Specification Issues Issue Type: Feature Request Components: Java SE Integration Affects Versions: 2.0-EDR1 Reporter: Antoine Sabot-Durand As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1. The current version has the following flaws: * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API. * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration. * Don't provide a nice way to programmatically configure the container behavior. That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/Weld.java] could be interesting -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Nov 2 12:15:22 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 02 Nov 2015 17:15:22 +0000 Subject: [cdi-dev] Tomorrow's meeting agenda Message-ID: Hi all, Tomorrow I'd like to talk about: - Java One feedback - https://issues.jboss.org/browse/CDI-558 : Metadata builder - https://issues.jboss.org/browse/CDI-568: Se bootstrap API evolution - AOP on producer / custom bean If you have other topic, feel free to send them. Regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151102/7a5073d5/attachment-0001.html From issues at jboss.org Tue Nov 3 06:36:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Nov 2015 06:36:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124704#comment-13124704 ] Antoine Sabot-Durand commented on CDI-558: ------------------------------------------ I have 3 concerns by having these accessible only in lifecycle event: * Consistency: why having some accessible in events and others elsewhere * It doesn't solve the problem of having a place to put AnnotatedTypeBuilder * It prevents creation of these meta data from outside CDI. The use could be to create a bean and use it in launching the container in SE or if we decide later to allow addition of some meta data at runtime. > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 3 06:50:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 3 Nov 2015 06:50:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124712#comment-13124712 ] Martin Kouba commented on CDI-558: ---------------------------------- bq. It doesn't solve the problem of having a place to put AnnotatedTypeBuilder It's true, on the other hand the AnnotatedTypeBuilder would be a bit special, i.e. it doesn't need a {{BeanManager}} instance unlike BeanBuilder using BM e.g. to create {{InjectionTarget}}. bq. The use could be to create a bean and use it in launching the container in SE CDI SE builder may allow to access these builders - see my previous comment. bq. or if we decide later to allow addition of some meta data at runtime Well, if we decide later we could add this later. I think it's a good start to have it only accessible where it's needed ATM. > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 3 08:27:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Nov 2015 08:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124779#comment-13124779 ] Antoine Sabot-Durand commented on CDI-558: ------------------------------------------ {quote}CDI SE builder may allow to access these builders - see my previous comment.{quote} Sorry, I missed that. {quote}{quote}or if we decide later to allow addition of some meta data at runtime{quote} Well, if we decide later we could add this later. I think it's a good start to have it only accessible where it's needed ATM. {quote} Ok, but that doesn't solve the place for {{AnnotatedTypeBuilder}}. Should it be one of the few helpers classes of our API in {{javax.enterprise.util}} package beside {{AnnotationLiteral}}? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 3 08:28:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 3 Nov 2015 08:28:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124779#comment-13124779 ] Antoine Sabot-Durand edited comment on CDI-558 at 11/3/15 8:27 AM: ------------------------------------------------------------------- {quote}CDI SE builder may allow to access these builders - see my previous comment.{quote} Sorry, I missed that. {quote} bq. or if we decide later to allow addition of some meta data at runtime Well, if we decide later we could add this later. I think it's a good start to have it only accessible where it's needed ATM. {quote} Ok, but that doesn't solve the place for {{AnnotatedTypeBuilder}}. Should it be one of the few helpers classes of our API in {{javax.enterprise.util}} package beside {{AnnotationLiteral}}? was (Author: antoinesabot-durand): {quote}CDI SE builder may allow to access these builders - see my previous comment.{quote} Sorry, I missed that. {quote}{quote}or if we decide later to allow addition of some meta data at runtime{quote} Well, if we decide later we could add this later. I think it's a good start to have it only accessible where it's needed ATM. {quote} Ok, but that doesn't solve the place for {{AnnotatedTypeBuilder}}. Should it be one of the few helpers classes of our API in {{javax.enterprise.util}} package beside {{AnnotationLiteral}}? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Nov 3 11:30:07 2015 From: antoine at sabot-durand.net (antoine at sabot-durand.net) Date: Tue, 03 Nov 2015 16:30:07 +0000 Subject: [cdi-dev] Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Tuesday except Tue Oct 6 18:00 or Tue Oct 13 18:00 (ASD Perso) Message-ID: <047d7b3a85d625d4900523a56844@google.com> This event has been changed. Title: CDI weekly meeting Weekly meeting of the CDI EG and other community members discussing CDI 2.0 specification. When: Weekly from 18:00 to 19:00 on Tuesday except Tue Oct 6 18:00 or Tue Oct 13 18:00 Paris (changed) Where: IRC #cdi-dev channel on freenode Calendar: ASD Perso Who: * Antoine Sabot-Durand - organizer * cdi-dev Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151103/257d074e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1764 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20151103/257d074e/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1818 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20151103/257d074e/attachment-0003.bin From issues at jboss.org Wed Nov 4 05:36:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 4 Nov 2015 05:36:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-545) Clarify that observers can't be remote business method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-545: ------------------------------------- Fix Version/s: 2.0-EDR2 > Clarify that observers can't be remote business method > ------------------------------------------------------- > > Key: CDI-545 > URL: https://issues.jboss.org/browse/CDI-545 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Priority: Major > Fix For: 2.0-EDR2 > > > In section 10.4 of 1.2 spec we have: > {quote} > If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class. > {quote} > in 10.4.2 we also have: > {quote} > If a non-static method of a session bean class has a parameter annotated {{@Observes}}, and the method is not a business method of the EJB, the container automatically detects the problem and treats it as a definition error. > {quote} > This 2 assertions don't prevent an observer to be a business method of a remote client of an EJB. We should be more precise here and forbid this scenario. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 05:39:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 4 Nov 2015 05:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-541: ------------------------------------- Fix Version/s: 2.0-EDR2 > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Priority: Major > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 05:48:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 4 Nov 2015 05:48:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-542) "10.2.2. Firing events asynchronously" update/enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125260#comment-13125260 ] Antoine Sabot-Durand commented on CDI-542: ------------------------------------------ Don't panic Tomas, nobody read the spec ;). More seriously, you're right, what I propose is to link the observer resolution section to fire and fireasync section. Regarding the second point it has been corrected with CDI-564 > "10.2.2. Firing events asynchronously" update/enhancements > ---------------------------------------------------------- > > Key: CDI-542 > URL: https://issues.jboss.org/browse/CDI-542 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter. > First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??) > I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy: > {quote} > * The event is fired synchronously and the observer is defined with @Observes. > * The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync. > {quote} > Second there is following sentence which TBH I have had fairly hard times to understand: > {quote} > If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately. > {quote} > ...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 05:48:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 4 Nov 2015 05:48:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-542) "10.2.2. Firing events asynchronously" update/enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-542: ------------------------------------- Fix Version/s: 2.0-EDR2 > "10.2.2. Firing events asynchronously" update/enhancements > ---------------------------------------------------------- > > Key: CDI-542 > URL: https://issues.jboss.org/browse/CDI-542 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter. > First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??) > I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy: > {quote} > * The event is fired synchronously and the observer is defined with @Observes. > * The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync. > {quote} > Second there is following sentence which TBH I have had fairly hard times to understand: > {quote} > If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately. > {quote} > ...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 05:49:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 4 Nov 2015 05:49:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-542) "10.2.2. Firing events asynchronously" update/enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-542 started by Antoine Sabot-Durand. ------------------------------------------------ > "10.2.2. Firing events asynchronously" update/enhancements > ---------------------------------------------------------- > > Key: CDI-542 > URL: https://issues.jboss.org/browse/CDI-542 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter. > First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??) > I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy: > {quote} > * The event is fired synchronously and the observer is defined with @Observes. > * The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync. > {quote} > Second there is following sentence which TBH I have had fairly hard times to understand: > {quote} > If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately. > {quote} > ...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 06:35:00 2015 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 4 Nov 2015 06:35:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125299#comment-13125299 ] Matej Novotny commented on CDI-541: ----------------------------------- If I get this correctly then setting different @Priority to async observers will result in one observer being notified later than the other (as in the example given above). But there is not really a way to tell that the async observer has finished its work hence I cannot rely on its job being finished (the underlaying data being changed for instance) while the other observer is already executing. Now the question I have - could you give me a scenario when I would need to have one observer notified later than the other while still not caring about the data they handle (not relying on when they are done executing)? And I mean a scenario which wouldn't end all the same when using async observers without @Priority. Obviously, there might be some but I just cannot see any atm so feel free to enlighten me :) > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Priority: Major > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 06:59:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 4 Nov 2015 06:59:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125311#comment-13125311 ] Martin Kouba commented on CDI-541: ---------------------------------- bq. But there is not really a way to tell that the async observer has finished its work... It is. Async observers with different priorities will have to be notified serially. An observer finishes its work when the {{notify()}} method completes. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Priority: Major > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 07:34:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 4 Nov 2015 07:34:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-569) Add @ObservesAsync where the spec mention @Observes In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-569: ---------------------------------------- Summary: Add @ObservesAsync where the spec mention @Observes Key: CDI-569 URL: https://issues.jboss.org/browse/CDI-569 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 2.0-EDR1 Reporter: Antoine Sabot-Durand In multiple places, the spec mention {{@Observes}}, mainly to forbid observer declaration in certain element. We should add {{@ObservesAsync}} to all these mentions as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 07:50:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 4 Nov 2015 07:50:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-569) Add @ObservesAsync where the spec mention @Observes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-569 started by Antoine Sabot-Durand. ------------------------------------------------ > Add @ObservesAsync where the spec mention @Observes > --------------------------------------------------- > > Key: CDI-569 > URL: https://issues.jboss.org/browse/CDI-569 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > In multiple places, the spec mention {{@Observes}}, mainly to forbid observer declaration in certain element. We should add {{@ObservesAsync}} to all these mentions as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 4 07:56:00 2015 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 4 Nov 2015 07:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125354#comment-13125354 ] Matej Novotny commented on CDI-541: ----------------------------------- I can see what you mean now. Previously I thought that it is just about invocation order and that the next observer won't be waiting till the previous (with higher priority) finishes. While this makes sense I feel it doesn't exactly follow the idea of loose coupling which goes hand in hand with async handling. Furthermore the 'fire and forget' approach might suffer from this as you might need to mind existing observers (that is if you don't intend to leave it default). Nevertheless, I can definitely see some use cases with the behavior you described. It certainly may come in handy when we want to allow behavior similar to that of sync observers but within a separate thread. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Nov 8 09:21:00 2015 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Sun, 8 Nov 2015 09:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-557) Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126627#comment-13126627 ] Mark Paluch commented on CDI-557: --------------------------------- CDI-499 mentions {{fireAsyncEvent()}} on the {{BeanManager}} API but it seems to be never implemented. > Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method > ---------------------------------------------------------------------------- > > Key: CDI-557 > URL: https://issues.jboss.org/browse/CDI-557 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Minor > > http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#event_metadata > In paragraph for isAsync method there is: > {quote} > isAsync() returns true if the event was fired with fireAsync() or fireAsyncEvent() methods otherwise returns false. > {quote} > AFAIK There is no such method. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Nov 8 09:25:00 2015 From: issues at jboss.org (Mark Paluch (JIRA)) Date: Sun, 8 Nov 2015 09:25:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-564) Async events simplification and clarification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126628#comment-13126628 ] Mark Paluch commented on CDI-564: --------------------------------- After checking the original async ticket I noticed CDI-499 mentions {{fireAsyncEvent()}} on the {{BeanManager}} API but it seems to be never implemented. CDI-557 reports the same issue, but the resolution was to remove textual references. > Async events simplification and clarification > --------------------------------------------- > > Key: CDI-564 > URL: https://issues.jboss.org/browse/CDI-564 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Following our F2F meeting, we decided to simplify Asynchronous event: > * {{FireAsync()}} should only triggers async observers > * Exception handling should be done with JDK 8 {{CompletionException}} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 9 08:32:00 2015 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Mon, 9 Nov 2015 08:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-224) Support Decoration of no interface beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126825#comment-13126825 ] Stephan Knitelius commented on CDI-224: --------------------------------------- I would also like to see this. [~pmuir] Can you clarify the problem? If the decorator extends the bean only methods defined in the abstract decorating bean should be considered as decorating methods and none of the inherited. > 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: Pete Muir > > 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) From issues at jboss.org Mon Nov 9 08:45:00 2015 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 9 Nov 2015 08:45:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-224) Support Decoration of no interface beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126832#comment-13126832 ] Pete Muir commented on CDI-224: ------------------------------- [~seasoned] The decorating types are automatically inferred from the class declaration. If we extend it to always include parent classes, then suddenly all of the parent types would be decorated in *existing applications* when the CDI upgrade is performed. This is not backwards compatible. You would need some way to enable the decorator in this case (for example, adding interfaces...) > 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: Pete Muir > > 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) From antoine at sabot-durand.net Mon Nov 9 12:38:51 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 09 Nov 2015 17:38:51 +0000 Subject: [cdi-dev] Next meeting on nov 24th Message-ID: Hi all, I'm at Devoxx BE this week and will be at Devoxx MA next week. So next meeting will be in 2 weeks. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151109/da76fca6/attachment.html From issues at jboss.org Tue Nov 10 03:55:01 2015 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Tue, 10 Nov 2015 03:55:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127133#comment-13127133 ] Stephan Knitelius commented on CDI-37: -------------------------------------- I guess his primary concern is that all the scopes imply that they are stateful in their respective contexts. Functionally @RequestScoped does the job, apart from its implied statefulness within a request. > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 10 14:39:00 2015 From: issues at jboss.org (Michael Remijan (JIRA)) Date: Tue, 10 Nov 2015 14:39:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: Michael Remijan created CDI-570: ----------------------------------- Summary: Weld shutdown in Java SE during asynch event calling Key: CDI-570 URL: https://issues.jboss.org/browse/CDI-570 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Affects Versions: 2.0-EDR1 Reporter: Michael Remijan In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 10 20:15:01 2015 From: issues at jboss.org (MohanKumar Gundappa (JIRA)) Date: Tue, 10 Nov 2015 20:15:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127562#comment-13127562 ] MohanKumar Gundappa commented on CDI-370: ----------------------------------------- Is there any alternate solution till this get's fixed? > Expand @RequestScoped and @SessionScoped to account for WebSocket > ----------------------------------------------------------------- > > Key: CDI-370 > URL: https://issues.jboss.org/browse/CDI-370 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > > We've been testing injection into a WebSocket endpoint. > @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope. > However if you try to use the injected object from within the @OnMessage callback you get a Weld error: > SEVERE: org.jboss.weld.context.ContextNotActiveException: > WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped > Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 02:17:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 11 Nov 2015 02:17:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127589#comment-13127589 ] Mark Struberg commented on CDI-570: ----------------------------------- This has not much to do with the CDI spec. It's imo a container implementation detail. How long should the shutdown wait on an async event? What if an async event hangs? Should the server still shut down? > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 02:23:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 11 Nov 2015 02:23:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-571) Producer and Disposer methods as remote business methods In-Reply-To: References: Message-ID: Tomas Remes created CDI-571: ------------------------------- Summary: Producer and Disposer methods as remote business methods Key: CDI-571 URL: https://issues.jboss.org/browse/CDI-571 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 2.0-EDR1, 1.2.Final Reporter: Tomas Remes Currently it's possible to declare Producer and Disposal for remote business method: {quote} if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. {quote} The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 02:24:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 11 Nov 2015 02:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-571) Producer and Disposer methods as remote business methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated CDI-571: ---------------------------- Description: Currently it's possible to declare remote business method as a Producer or Disposer method: {quote} if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. {quote} The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. was: Currently it's possible to declare Producer and Disposal for remote business method: {quote} if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. {quote} The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. > Producer and Disposer methods as remote business methods > -------------------------------------------------------- > > Key: CDI-571 > URL: https://issues.jboss.org/browse/CDI-571 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Tomas Remes > > Currently it's possible to declare remote business method as a Producer or Disposer method: > {quote} > if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. > {quote} > The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 02:31:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 11 Nov 2015 02:31:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127591#comment-13127591 ] Tomas Remes commented on CDI-570: --------------------------------- Yes I tend to agree with Mark. These are good questions and I am not really sure if we can specify something like "graceful" shutdown. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 02:51:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 11 Nov 2015 02:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127598#comment-13127598 ] Mark Struberg commented on CDI-570: ----------------------------------- Yes, it's a whole category of problems. This not only affects shutdown but also normal runtime. If a synchronous event gets stuck then you can easily detect it. But if an async event get stuck then it might remain unnoticed for quite some time. Deadlocks might also occur much easier. We might probably think about introducing something like @AbortAfter(60000) ? Of course it makes all the CDI impls more heavyweight once we start with such things. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 03:09:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 11 Nov 2015 03:09:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127599#comment-13127599 ] Martin Kouba commented on CDI-570: ---------------------------------- -1 for introducing "graceful" shutdown into CDI SE or something like @AbortAfter - this could bring a pile of other questions and problems, e.g. what about async events with custom Executor. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 03:13:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 11 Nov 2015 03:13:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127601#comment-13127601 ] Mark Struberg commented on CDI-570: ----------------------------------- But we at least must make users aware that it is THEIR problem to track those things? Not as nice... > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 03:29:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 11 Nov 2015 03:29:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127607#comment-13127607 ] Martin Kouba commented on CDI-570: ---------------------------------- Well, event payload mutability/synchronization is also a user problem. I think it's a kind of problem users should be aware of when using async events. +1 for adding some (probably non-normative) info about this stuff. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 03:42:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 11 Nov 2015 03:42:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127611#comment-13127611 ] Mark Struberg commented on CDI-570: ----------------------------------- Many server have a thread stuck warning. That is causes enerving warnings if the job in question is especially designed to be long running (and properly shuts down itself on request). Something in the spec which could denote such a thread would be welcome. Of course that is not a CDI problem otoh but such feature should be a more generic one. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Wed Nov 11 14:47:39 2015 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 11 Nov 2015 20:47:39 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB Message-ID: Hi! We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. Any objections, any ideas, any howtos? Let the ideas roll ;) LieGrue, strub From rmannibucau at gmail.com Wed Nov 11 14:54:48 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 11 Nov 2015 11:54:48 -0800 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: Message-ID: Hi Mark, few points on that topic: - let the EJB container reuse AnnotatedType (ie even add @Stateless through an Extension): +1 - veto an EJB as a whole and not only in CDI side - ie @Schedule is ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it would break the compatibility with extsing apps I fear since veto is 100% a CDI thing today. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-11-11 11:47 GMT-08:00 Mark Struberg : > Hi! > > We already do a decent amount of ?side-by-side? handling in EJB and CDI. > But there are still many aready where we could really move together much > closer. > > E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the > EJB container. But what happens with ProcessAnnotatedType#veto(). This one > is not defined that clearly I fear. > > What if we (of course together with the EJB spec group) define that the > EJB container must create the EJBs according to the effective AnnotatedType > coming out after ProcessAnnotatedType? This would define that EJBs can also > get modified via CDI Extensions. Some container do that already. > The benefit of explicitly writing this down would obviously be that we > would allow EJB to fully utilize the power of CDI Extensions in a portable > way. > > Any objections, any ideas, any howtos? > > Let the ideas roll ;) > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151111/82bc6f12/attachment.html From rmannibucau at gmail.com Wed Nov 11 15:17:18 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 11 Nov 2015 12:17:18 -0800 Subject: [cdi-dev] Unwrappable proxies Message-ID: Hi guys, any plan to work on https://issues.jboss.org/browse/CDI-10 ? There is a discussion about jbatch/bval integration pending on CDI technical side linked to this one. A quick status would be appreciated to be able to go forward on the current discussion. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151111/15658140/attachment.html From issues at jboss.org Wed Nov 11 16:30:00 2015 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 11 Nov 2015 16:30:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127979#comment-13127979 ] Stephan Knitelius commented on CDI-10: -------------------------------------- I believe this is also an issue with Vaadin CDI integration. At the moment all Vaadin UI components are not allowed to have a normal scope since Vaadin cannot handle CDI proxies. Vaadin CDI has solves this, at the moment by providing all supported scopes once as normal scope and once as pseudo scoped. JavaDoc from @NormalViewScoped: {quote} * You cannot use this scope with Vaadin Components. Proxy Components do not * work correctly within the Vaadin framework, so as a precaution the Vaadin * CDI plugin will not deploy if any such beans are discovered. {quote} > 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 > > 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) From issues at jboss.org Wed Nov 11 16:50:00 2015 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 11 Nov 2015 16:50:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-37) Stateless scope In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127983#comment-13127983 ] Stephan Knitelius commented on CDI-37: -------------------------------------- I think this issue should be closed, as it really just comes down to semantics. > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Nov 11 16:56:00 2015 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 11 Nov 2015 16:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127985#comment-13127985 ] Stephan Knitelius commented on CDI-541: --------------------------------------- The idea of calling Async observers serially seems a bit odd to me. As pointed out by Matej, it kind of breaks the idea of loose coupling and async processing. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Thu Nov 12 02:37:36 2015 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 12 Nov 2015 08:37:36 +0100 Subject: [cdi-dev] Unwrappable proxies In-Reply-To: References: Message-ID: <564441C0.8070304@redhat.com> Hi Romain, I believe this might be useful (especially for integration use cases) and should be addressed in 2.0. Antoine pls could we add this to the agenda for the next CDI EG mtg? Martin Dne 11.11.2015 v 21:17 Romain Manni-Bucau napsal(a): > Hi guys, > > any plan to work on https://issues.jboss.org/browse/CDI-10 ? > > There is a discussion about jbatch/bval integration pending on CDI > technical side linked to this one. > > A quick status would be appreciated to be able to go forward on the > current discussion. > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Thu Nov 12 02:46:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 12 Nov 2015 02:46:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128042#comment-13128042 ] Mark Struberg commented on CDI-10: ---------------------------------- We would also need to clarify what kind of unwrapping needs to be performed. In OWB-1.2.x ++ we have a stack of proxies on top of each other. In the maximum scenario we could get a 1.) NormalScoping Proxy 2.) Interceptor/Decorator Proxy 3.) subclassing proxy if there are abstract Decorators involved Sometimes you like to get the Contextual Instance with all it's Interceptors and Decorators, but at some other time you need the real underlying delegation instance (the _native_ instance without anything else). The second case is needed if you e.g. like to perform JSR-303 validation on the whole bean. Or if you like to call private methods on that bean (e.g. delivering messages, etc). Please note that we need to think about security as well! This needs to be done as doPrivileged block at least. Not sure what else is necessary to prevent abuse. > 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 > > 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) From issues at jboss.org Thu Nov 12 02:52:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Nov 2015 02:52:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-10: ------------------------------------ Fix Version/s: 2.0 (discussion) > 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 > 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) From antoine at sabot-durand.net Thu Nov 12 02:53:13 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 12 Nov 2015 07:53:13 +0000 Subject: [cdi-dev] Unwrappable proxies In-Reply-To: <564441C0.8070304@redhat.com> References: <564441C0.8070304@redhat.com> Message-ID: Yes I'd like to work on this issue. I submitted more complicated issue resolving the same problem (CDI-561). Le jeu. 12 nov. 2015 ? 08:37, Martin Kouba a ?crit : > Hi Romain, > > I believe this might be useful (especially for integration use cases) > and should be addressed in 2.0. Antoine pls could we add this to the > agenda for the next CDI EG mtg? > > Martin > > Dne 11.11.2015 v 21:17 Romain Manni-Bucau napsal(a): > > Hi guys, > > > > any plan to work on https://issues.jboss.org/browse/CDI-10 ? > > > > There is a discussion about jbatch/bval integration pending on CDI > > technical side linked to this one. > > > > A quick status would be appreciated to be able to go forward on the > > current discussion. > > > > Romain Manni-Bucau > > @rmannibucau | Blog > > | Github > > | LinkedIn > > | Tomitriber > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151112/7ecfe22b/attachment.html From issues at jboss.org Thu Nov 12 03:03:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Nov 2015 03:03:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128046#comment-13128046 ] Martin Kouba commented on CDI-561: ---------------------------------- bq. Accessing the true class of the instance in a clean way... Just note that the class of a contextual instance might not be the class one would expect because a contextual instance is an internal container construct (for example in Weld it might be a subclass). > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Nov 12 03:08:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Nov 2015 03:08:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128049#comment-13128049 ] Martin Kouba commented on CDI-10: --------------------------------- Good points Mark. We should also keep in mind that a contextual instance is an internal container construct. For example in Weld, if Foo is intercepted/decorated then Foo contextual instance is an instance of a Foo's subclass (internal Weld construct). > 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 > 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) From issues at jboss.org Thu Nov 12 03:21:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 12 Nov 2015 03:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-572) support JSR-303 bean validation in CDI beans In-Reply-To: References: Message-ID: Mark Struberg created CDI-572: --------------------------------- Summary: support JSR-303 bean validation in CDI beans Key: CDI-572 URL: https://issues.jboss.org/browse/CDI-572 Project: CDI Specification Issues Issue Type: Epic Reporter: Mark Struberg Consider a bean like {code} @SessionScoped public class CurrentUser { @javax.validation.constraint.NotNull @javax.validation.constraint.Length(10) private String userId; ... } {code} We could easily check this and invoke JSR-303 (if available) in the Producer. Please note that for a custom Producer they have to care for it themselves. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Nov 12 03:37:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Nov 2015 03:37:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-572) support JSR-303 bean validation in CDI beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128060#comment-13128060 ] Martin Kouba commented on CDI-572: ---------------------------------- [~struberg] Isn't there {{@Inject}} missing in the example? > support JSR-303 bean validation in CDI beans > -------------------------------------------- > > Key: CDI-572 > URL: https://issues.jboss.org/browse/CDI-572 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Mark Struberg > > Consider a bean like > {code} > @SessionScoped > public class CurrentUser { > @javax.validation.constraint.NotNull > @javax.validation.constraint.Length(10) > private String userId; > ... > } > {code} > We could easily check this and invoke JSR-303 (if available) in the Producer. Please note that for a custom Producer they have to care for it themselves. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Nov 12 03:46:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Nov 2015 03:46:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-572) support JSR-303 bean validation in CDI beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128064#comment-13128064 ] Martin Kouba commented on CDI-572: ---------------------------------- Also what should happen if a validation fails? > support JSR-303 bean validation in CDI beans > -------------------------------------------- > > Key: CDI-572 > URL: https://issues.jboss.org/browse/CDI-572 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Mark Struberg > > Consider a bean like > {code} > @SessionScoped > public class CurrentUser { > @javax.validation.constraint.NotNull > @javax.validation.constraint.Length(10) > private String userId; > ... > } > {code} > We could easily check this and invoke JSR-303 (if available) in the Producer. Please note that for a custom Producer they have to care for it themselves. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Nov 12 04:18:00 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Thu, 12 Nov 2015 04:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-572) support JSR-303 bean validation in CDI beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128077#comment-13128077 ] Sven Linstaedt commented on CDI-572: ------------------------------------ Something like {{javax.enterprise.inject.InvalidResolutionException}} ? Seriously one can also argue for validation annotations being qualifiers, so ambigous beans for injection point may exists as along as exactly one of them passes validation. Which ultimately renders injection point validation being a runtime validation, not performable a bootstrap time. > support JSR-303 bean validation in CDI beans > -------------------------------------------- > > Key: CDI-572 > URL: https://issues.jboss.org/browse/CDI-572 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Mark Struberg > > Consider a bean like > {code} > @SessionScoped > public class CurrentUser { > @javax.validation.constraint.NotNull > @javax.validation.constraint.Length(10) > private String userId; > ... > } > {code} > We could easily check this and invoke JSR-303 (if available) in the Producer. Please note that for a custom Producer they have to care for it themselves. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Nov 12 04:34:00 2015 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Thu, 12 Nov 2015 04:34:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128080#comment-13128080 ] Sven Linstaedt commented on CDI-10: ----------------------------------- For the purpose of reading class metadata (fields, methods, annotations, ...) of bean instances one can also make their Beans (and maybe also AnnotatedType, so other frameworks benefit from metadata being overridable) able to lookup. E.g. via BeanManager like BeanManager#lookupBeanOf(T proxy), so their is no need to unproxy bean references just for being able to access their java type. > 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 > 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) From sven.linstaedt at gmail.com Thu Nov 12 04:45:22 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Thu, 12 Nov 2015 10:45:22 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: Message-ID: +1 for splitting the classpath scanning and all AnnotatedXXX / ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, so other specs (not only EJB) may rely on it. 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau : > Hi Mark, > > few points on that topic: > > - let the EJB container reuse AnnotatedType (ie even add @Stateless > through an Extension): +1 > - veto an EJB as a whole and not only in CDI side - ie @Schedule is > ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it > would break the compatibility with extsing apps I fear since veto is 100% a > CDI thing today. > > > > Romain Manni-Bucau > @rmannibucau | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-11-11 11:47 GMT-08:00 Mark Struberg : > >> Hi! >> >> We already do a decent amount of ?side-by-side? handling in EJB and CDI. >> But there are still many aready where we could really move together much >> closer. >> >> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the >> EJB container. But what happens with ProcessAnnotatedType#veto(). This one >> is not defined that clearly I fear. >> >> What if we (of course together with the EJB spec group) define that the >> EJB container must create the EJBs according to the effective AnnotatedType >> coming out after ProcessAnnotatedType? This would define that EJBs can also >> get modified via CDI Extensions. Some container do that already. >> The benefit of explicitly writing this down would obviously be that we >> would allow EJB to fully utilize the power of CDI Extensions in a portable >> way. >> >> Any objections, any ideas, any howtos? >> >> Let the ideas roll ;) >> >> LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151112/b6ef581f/attachment.html From issues at jboss.org Thu Nov 12 04:56:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 12 Nov 2015 04:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128093#comment-13128093 ] Martin Kouba commented on CDI-10: --------------------------------- [~tzwoenn] Good point as well. However, not all beans come from an AnnotatedType (e.g. producer methods, custom beans, etc.) so it's not 1:1 relation. The topic is complicated. We should be careful here. > 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 > 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) From tremes at redhat.com Thu Nov 12 05:12:40 2015 From: tremes at redhat.com (Tomas Remes) Date: Thu, 12 Nov 2015 05:12:40 -0500 (EST) Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: Message-ID: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> I think nothing will happen in EJB spec so I would not really rely on some future collaboration. Another case is this classpath scanning and AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at least at first glance.:) But the question is: Isn't it late to propose any new JSR for upcoming EE 8? I guess it is so this seems to me bit out of scope for CDI 2.x... maybe CDI 3?:) Tom ----- Original Message ----- From: "Sven Linstaedt" To: "Romain Manni-Bucau" Cc: "cdi-dev" Sent: Thursday, November 12, 2015 10:45:22 AM Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB +1 for splitting the classpath scanning and all AnnotatedXXX / ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, so other specs (not only EJB) may rely on it. 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com > : Hi Mark, few points on that topic: - let the EJB container reuse AnnotatedType (ie even add @Stateless through an Extension): +1 - veto an EJB as a whole and not only in CDI side - ie @Schedule is ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it would break the compatibility with extsing apps I fear since veto is 100% a CDI thing today. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > : Hi! We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. Any objections, any ideas, any howtos? Let the ideas roll ;) LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -- Tomas Remes From antoine at sabot-durand.net Thu Nov 12 05:45:42 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 12 Nov 2015 10:45:42 +0000 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> References: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> Message-ID: >From my POV problems are: - EJB spec totally ignore CDI (it's CDI that does all the job of EJB integration) - EJB spec won't be reopened except for minor MR - I launched the proposition for a new spec based on our AnnotatedType meta model when we were discussing about config spec. I didn't have enough support from Red Hat and EG so I put it back in my drawer. Antoine Le jeu. 12 nov. 2015 ? 11:17, Tomas Remes a ?crit : > > I think nothing will happen in EJB spec so I would not really rely on some > future collaboration. Another case is this classpath scanning and > AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at > least at first glance.:) But the question is: Isn't it late to propose any > new JSR for upcoming EE 8? I guess it is so this seems to me bit out of > scope for CDI 2.x... maybe CDI 3?:) > > Tom > > ----- Original Message ----- > From: "Sven Linstaedt" > To: "Romain Manni-Bucau" > Cc: "cdi-dev" > Sent: Thursday, November 12, 2015 10:45:22 AM > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > +1 for splitting the classpath scanning and all AnnotatedXXX / > ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, > so other specs (not only EJB) may rely on it. > > 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com > : > > > > Hi Mark, > > few points on that topic: > > - let the EJB container reuse AnnotatedType (ie even add @Stateless > through an Extension): +1 > - veto an EJB as a whole and not only in CDI side - ie @Schedule is > ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it > would break the compatibility with extsing apps I fear since veto is 100% a > CDI thing today. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > : > > > Hi! > > We already do a decent amount of ?side-by-side? handling in EJB and CDI. > But there are still many aready where we could really move together much > closer. > > E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the > EJB container. But what happens with ProcessAnnotatedType#veto(). This one > is not defined that clearly I fear. > > What if we (of course together with the EJB spec group) define that the > EJB container must create the EJBs according to the effective AnnotatedType > coming out after ProcessAnnotatedType? This would define that EJBs can also > get modified via CDI Extensions. Some container do that already. > The benefit of explicitly writing this down would obviously be that we > would allow EJB to fully utilize the power of CDI Extensions in a portable > way. > > Any objections, any ideas, any howtos? > > Let the ideas roll ;) > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -- > Tomas Remes > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151112/66185bd2/attachment-0001.html From john.d.ament at gmail.com Thu Nov 12 07:51:57 2015 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 12 Nov 2015 12:51:57 +0000 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> Message-ID: Splitting out into more specs probably won't solve the issue. My honest opinion is that neither CDI nor EJB should describe how the other spec works. The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI is available, these additional things occur. The probably is that CDI has already describe certain aspects about EJB. Because of that, its likely ours forever. The way most of these other services operate, it feels like they're all app server level integrations. So why wouldn't the entire EE ecosystem be described at the EE level? On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > From my POV problems are: > > - EJB spec totally ignore CDI (it's CDI that does all the job of EJB > integration) > - EJB spec won't be reopened except for minor MR > - I launched the proposition for a new spec based on our AnnotatedType > meta model when we were discussing about config spec. I didn't have enough > support from Red Hat and EG so I put it back in my drawer. > > Antoine > > Le jeu. 12 nov. 2015 ? 11:17, Tomas Remes a ?crit : > >> >> I think nothing will happen in EJB spec so I would not really rely on >> some future collaboration. Another case is this classpath scanning and >> AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at >> least at first glance.:) But the question is: Isn't it late to propose any >> new JSR for upcoming EE 8? I guess it is so this seems to me bit out of >> scope for CDI 2.x... maybe CDI 3?:) >> >> Tom >> >> ----- Original Message ----- >> From: "Sven Linstaedt" >> To: "Romain Manni-Bucau" >> Cc: "cdi-dev" >> Sent: Thursday, November 12, 2015 10:45:22 AM >> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> >> +1 for splitting the classpath scanning and all AnnotatedXXX / >> ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, >> so other specs (not only EJB) may rely on it. >> >> 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com > : >> >> >> >> Hi Mark, >> >> few points on that topic: >> >> - let the EJB container reuse AnnotatedType (ie even add @Stateless >> through an Extension): +1 >> - veto an EJB as a whole and not only in CDI side - ie @Schedule is >> ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it >> would break the compatibility with extsing apps I fear since veto is 100% a >> CDI thing today. >> >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > : >> >> >> Hi! >> >> We already do a decent amount of ?side-by-side? handling in EJB and CDI. >> But there are still many aready where we could really move together much >> closer. >> >> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the >> EJB container. But what happens with ProcessAnnotatedType#veto(). This one >> is not defined that clearly I fear. >> >> What if we (of course together with the EJB spec group) define that the >> EJB container must create the EJBs according to the effective AnnotatedType >> coming out after ProcessAnnotatedType? This would define that EJBs can also >> get modified via CDI Extensions. Some container do that already. >> The benefit of explicitly writing this down would obviously be that we >> would allow EJB to fully utilize the power of CDI Extensions in a portable >> way. >> >> Any objections, any ideas, any howtos? >> >> Let the ideas roll ;) >> >> LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> -- >> Tomas Remes >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151112/5ddc72b5/attachment.html From rmannibucau at gmail.com Thu Nov 12 09:41:40 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 12 Nov 2015 06:41:40 -0800 Subject: [cdi-dev] Unwrappable proxies In-Reply-To: References: <564441C0.8070304@redhat.com> Message-ID: Looks good bit maybe we should keep things split: accessing an instance in its scope is "easy" - ie all impl can do it - but copying an instance is hard cause this instance can expect to be finished/no more usable. Just dont want to have a blocker on first part cause of the second. Can 561 become the second and 10 stay the first maybe? Le 11 nov. 2015 23:53, "Antoine Sabot-Durand" a ?crit : > Yes I'd like to work on this issue. I submitted more complicated issue > resolving the same problem (CDI-561). > > > Le jeu. 12 nov. 2015 ? 08:37, Martin Kouba a ?crit : > >> Hi Romain, >> >> I believe this might be useful (especially for integration use cases) >> and should be addressed in 2.0. Antoine pls could we add this to the >> agenda for the next CDI EG mtg? >> >> Martin >> >> Dne 11.11.2015 v 21:17 Romain Manni-Bucau napsal(a): >> > Hi guys, >> > >> > any plan to work on https://issues.jboss.org/browse/CDI-10 ? >> > >> > There is a discussion about jbatch/bval integration pending on CDI >> > technical side linked to this one. >> > >> > A quick status would be appreciated to be able to go forward on the >> > current discussion. >> > >> > Romain Manni-Bucau >> > @rmannibucau | Blog >> > | Github >> > | LinkedIn >> > | Tomitriber >> > >> > >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151112/c14fe19e/attachment.html From rmannibucau at gmail.com Thu Nov 12 09:46:24 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 12 Nov 2015 06:46:24 -0800 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> Message-ID: Le 12 nov. 2015 04:52, "John D. Ament" a ?crit : > > Splitting out into more specs probably won't solve the issue. My honest opinion is that neither CDI nor EJB should describe how the other spec works. The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI is available, these additional things occur. > > The probably is that CDI has already describe certain aspects about EJB. Because of that, its likely ours forever. > > The way most of these other services operate, it feels like they're all app server level integrations. So why wouldn't the entire EE ecosystem be described at the EE level? Sounds legitimate from an organisation point of view but not consistent from a technical point of view. Why ensuring all spec redefine the same things and just trying to make them fit if possible instead of ensuring they can share the same technical stack when a need is shared - more or less all major spec need scanning? That said it needs to be moved to EE as a change in the way spec are driven ans not just there IMO. > > > On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: >> >> From my POV problems are: >> >> - EJB spec totally ignore CDI (it's CDI that does all the job of EJB integration) >> - EJB spec won't be reopened except for minor MR >> - I launched the proposition for a new spec based on our AnnotatedType meta model when we were discussing about config spec. I didn't have enough support from Red Hat and EG so I put it back in my drawer. >> >> Antoine >> >> Le jeu. 12 nov. 2015 ? 11:17, Tomas Remes a ?crit : >>> >>> >>> I think nothing will happen in EJB spec so I would not really rely on some future collaboration. Another case is this classpath scanning and AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at least at first glance.:) But the question is: Isn't it late to propose any new JSR for upcoming EE 8? I guess it is so this seems to me bit out of scope for CDI 2.x... maybe CDI 3?:) >>> >>> Tom >>> >>> ----- Original Message ----- >>> From: "Sven Linstaedt" >>> To: "Romain Manni-Bucau" >>> Cc: "cdi-dev" >>> Sent: Thursday, November 12, 2015 10:45:22 AM >>> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >>> >>> +1 for splitting the classpath scanning and all AnnotatedXXX / ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, so other specs (not only EJB) may rely on it. >>> >>> 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com > : >>> >>> >>> >>> Hi Mark, >>> >>> few points on that topic: >>> >>> - let the EJB container reuse AnnotatedType (ie even add @Stateless through an Extension): +1 >>> - veto an EJB as a whole and not only in CDI side - ie @Schedule is ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it would break the compatibility with extsing apps I fear since veto is 100% a CDI thing today. >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > : >>> >>> >>> Hi! >>> >>> We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. >>> >>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >>> >>> What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. >>> The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. >>> >>> Any objections, any ideas, any howtos? >>> >>> Let the ideas roll ;) >>> >>> LieGrue, >>> strub >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> -- >>> Tomas Remes >>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151112/93f04e91/attachment-0001.html From issues at jboss.org Thu Nov 12 10:25:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 12 Nov 2015 10:25:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-572) support JSR-303 bean validation in CDI beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128343#comment-13128343 ] Mark Struberg commented on CDI-572: ----------------------------------- [~mkouba] yes, @Inject might be needed. But one could also use @PostConstruct to init this field. Or use Method injection. All that doesn't matter. Point is that _after_ all the injection was done and the instance is fully initialized it could be useful to invoke JSR-303 on it. > Also what should happen if a validation fails? Well that's a good question. What happens if there is some Exception in @PostConstruct? Guess the same should happen here as well. Or even throw a nice validation Exception. I agree with [[~Sven Linstaedt] that those checks only make sense at runtime. It might as well be that it fails for one request but passes for another one... If you think about business data producers this also makes perfect sense. > support JSR-303 bean validation in CDI beans > -------------------------------------------- > > Key: CDI-572 > URL: https://issues.jboss.org/browse/CDI-572 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Mark Struberg > > Consider a bean like > {code} > @SessionScoped > public class CurrentUser { > @javax.validation.constraint.NotNull > @javax.validation.constraint.Length(10) > private String userId; > ... > } > {code} > We could easily check this and invoke JSR-303 (if available) in the Producer. Please note that for a custom Producer they have to care for it themselves. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Nov 12 10:27:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 12 Nov 2015 10:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128346#comment-13128346 ] Mark Struberg commented on CDI-10: ---------------------------------- In OWB we also store the already decorated/intercepted instance in the Contexts. That's the reason why the 'unrolling' sometimes need to look through all the proxies in the chain. > 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 > 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) From issues at jboss.org Thu Nov 12 10:32:00 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 12 Nov 2015 10:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128352#comment-13128352 ] Romain Manni-Bucau commented on CDI-10: --------------------------------------- About the need: a not cdi proxy friendly lib will not identify the class of the proxied instance and fields if not forwarded so the user type instance can be needed to do vallidation, state update etc...we can argue the lib can become cdi bit the opposite should be doable, ie let a dev integrate cdi with a not cdi lib IMO. Technically I agree with Mark we need a way to define the unwrapping level we want. > 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 > 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) From issues at jboss.org Thu Nov 12 10:35:02 2015 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 12 Nov 2015 10:35:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-572) support JSR-303 bean validation in CDI beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128354#comment-13128354 ] Romain Manni-Bucau commented on CDI-572: ---------------------------------------- Cdi-bval current integration is in bval. -1 to have a cycle in term of dependency. Also would look like cdi would become the new ejb taking ee integration . We should move forward letting the integration in bval and adding the needed API IMHO. > support JSR-303 bean validation in CDI beans > -------------------------------------------- > > Key: CDI-572 > URL: https://issues.jboss.org/browse/CDI-572 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Mark Struberg > > Consider a bean like > {code} > @SessionScoped > public class CurrentUser { > @javax.validation.constraint.NotNull > @javax.validation.constraint.Length(10) > private String userId; > ... > } > {code} > We could easily check this and invoke JSR-303 (if available) in the Producer. Please note that for a custom Producer they have to care for it themselves. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Thu Nov 12 11:00:21 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 12 Nov 2015 17:00:21 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> Message-ID: <80D72802-D392-4CA7-A1B3-FCAE4AE82ADB@yahoo.de> > So why wouldn?t the entire EE ecosystem be described at the EE level? Perfectly nailed. But here is the problem: the EE umbrella does NOT do code. It does NOT provide an own TCK. It just packages together the other specs (and sometimes imposes restrictions and additional features on it). LieGrue, strub > Am 12.11.2015 um 13:51 schrieb John D. Ament : > > Splitting out into more specs probably won't solve the issue. My honest opinion is that neither CDI nor EJB should describe how the other spec works. The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI is available, these additional things occur. > > The probably is that CDI has already describe certain aspects about EJB. Because of that, its likely ours forever. > > The way most of these other services operate, it feels like they're all app server level integrations. So why wouldn't the entire EE ecosystem be described at the EE level? > > On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand wrote: > From my POV problems are: > > - EJB spec totally ignore CDI (it's CDI that does all the job of EJB integration) > - EJB spec won't be reopened except for minor MR > - I launched the proposition for a new spec based on our AnnotatedType meta model when we were discussing about config spec. I didn't have enough support from Red Hat and EG so I put it back in my drawer. > > Antoine > > Le jeu. 12 nov. 2015 ? 11:17, Tomas Remes a ?crit : > > I think nothing will happen in EJB spec so I would not really rely on some future collaboration. Another case is this classpath scanning and AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at least at first glance.:) But the question is: Isn't it late to propose any new JSR for upcoming EE 8? I guess it is so this seems to me bit out of scope for CDI 2.x... maybe CDI 3?:) > > Tom > > ----- Original Message ----- > From: "Sven Linstaedt" > To: "Romain Manni-Bucau" > Cc: "cdi-dev" > Sent: Thursday, November 12, 2015 10:45:22 AM > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > +1 for splitting the classpath scanning and all AnnotatedXXX / ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, so other specs (not only EJB) may rely on it. > > 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com > : > > > > Hi Mark, > > few points on that topic: > > - let the EJB container reuse AnnotatedType (ie even add @Stateless through an Extension): +1 > - veto an EJB as a whole and not only in CDI side - ie @Schedule is ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it would break the compatibility with extsing apps I fear since veto is 100% a CDI thing today. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > : > > > Hi! > > We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. > > E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. > > What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. > The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. > > Any objections, any ideas, any howtos? > > Let the ideas roll ;) > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > -- > Tomas Remes > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From sven.linstaedt at gmail.com Fri Nov 13 03:49:04 2015 From: sven.linstaedt at gmail.com (Sven Linstaedt) Date: Fri, 13 Nov 2015 09:49:04 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: <80D72802-D392-4CA7-A1B3-FCAE4AE82ADB@yahoo.de> References: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> <80D72802-D392-4CA7-A1B3-FCAE4AE82ADB@yahoo.de> Message-ID: Well, that was my point of splitting out these metadata scanning and processing into an independent spec, which CDI will depend on and maybe EJB in some future too, if their EG adopts it. As there is no global inter-spec coordination for - Mark called it - "EE umbrella" one can simply have a chat with them and keep the fingers crossed. br, Sven 2015-11-12 17:00 GMT+01:00 Mark Struberg : > > So why wouldn?t the entire EE ecosystem be described at the EE level? > > Perfectly nailed. > But here is the problem: the EE umbrella does NOT do code. It does NOT > provide an own TCK. It just packages together the other specs (and > sometimes imposes restrictions and additional features on it). > > LieGrue, > strub > > > > Am 12.11.2015 um 13:51 schrieb John D. Ament : > > > > Splitting out into more specs probably won't solve the issue. My honest > opinion is that neither CDI nor EJB should describe how the other spec > works. The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI > is available, these additional things occur. > > > > The probably is that CDI has already describe certain aspects about > EJB. Because of that, its likely ours forever. > > > > The way most of these other services operate, it feels like they're all > app server level integrations. So why wouldn't the entire EE ecosystem be > described at the EE level? > > > > On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > > From my POV problems are: > > > > - EJB spec totally ignore CDI (it's CDI that does all the job of EJB > integration) > > - EJB spec won't be reopened except for minor MR > > - I launched the proposition for a new spec based on our AnnotatedType > meta model when we were discussing about config spec. I didn't have enough > support from Red Hat and EG so I put it back in my drawer. > > > > Antoine > > > > Le jeu. 12 nov. 2015 ? 11:17, Tomas Remes a ?crit : > > > > I think nothing will happen in EJB spec so I would not really rely on > some future collaboration. Another case is this classpath scanning and > AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at > least at first glance.:) But the question is: Isn't it late to propose any > new JSR for upcoming EE 8? I guess it is so this seems to me bit out of > scope for CDI 2.x... maybe CDI 3?:) > > > > Tom > > > > ----- Original Message ----- > > From: "Sven Linstaedt" > > To: "Romain Manni-Bucau" > > Cc: "cdi-dev" > > Sent: Thursday, November 12, 2015 10:45:22 AM > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > > > +1 for splitting the classpath scanning and all AnnotatedXXX / > ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, > so other specs (not only EJB) may rely on it. > > > > 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com > > : > > > > > > > > Hi Mark, > > > > few points on that topic: > > > > - let the EJB container reuse AnnotatedType (ie even add @Stateless > through an Extension): +1 > > - veto an EJB as a whole and not only in CDI side - ie @Schedule is > ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it > would break the compatibility with extsing apps I fear since veto is 100% a > CDI thing today. > > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > > 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > : > > > > > > Hi! > > > > We already do a decent amount of ?side-by-side? handling in EJB and CDI. > But there are still many aready where we could really move together much > closer. > > > > E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the > EJB container. But what happens with ProcessAnnotatedType#veto(). This one > is not defined that clearly I fear. > > > > What if we (of course together with the EJB spec group) define that the > EJB container must create the EJBs according to the effective AnnotatedType > coming out after ProcessAnnotatedType? This would define that EJBs can also > get modified via CDI Extensions. Some container do that already. > > The benefit of explicitly writing this down would obviously be that we > would allow EJB to fully utilize the power of CDI Extensions in a portable > way. > > > > Any objections, any ideas, any howtos? > > > > Let the ideas roll ;) > > > > LieGrue, > > strub > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > > Tomas Remes > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151113/9ab067a1/attachment-0001.html From struberg at yahoo.de Fri Nov 13 07:58:38 2015 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 13 Nov 2015 13:58:38 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <1615227584.13880064.1447323160660.JavaMail.zimbra@redhat.com> <80D72802-D392-4CA7-A1B3-FCAE4AE82ADB@yahoo.de> Message-ID: <39454C62-48C6-4815-A50E-63494BD95C3C@yahoo.de> Well there is such an EG for the umbrella. For EE6 it was JSR-316, EE7 is JSR-342 and EE8 is JSR-366. They also write some spec text. You can e.g. see that they impose CDI features on EJB starting with JSR-316. But the EE umbrella spec does not have any _own_ code. It?s just coordination and papers. LieGrue, strub > Am 13.11.2015 um 09:49 schrieb Sven Linstaedt : > > Well, that was my point of splitting out these metadata scanning and processing into an independent spec, which CDI will depend on and maybe EJB in some future too, if their EG adopts it. As there is no global inter-spec coordination for - Mark called it - "EE umbrella" one can simply have a chat with them and keep the fingers crossed. > > br, Sven > > 2015-11-12 17:00 GMT+01:00 Mark Struberg : > > So why wouldn?t the entire EE ecosystem be described at the EE level? > > Perfectly nailed. > But here is the problem: the EE umbrella does NOT do code. It does NOT provide an own TCK. It just packages together the other specs (and sometimes imposes restrictions and additional features on it). > > LieGrue, > strub > > > > Am 12.11.2015 um 13:51 schrieb John D. Ament : > > > > Splitting out into more specs probably won't solve the issue. My honest opinion is that neither CDI nor EJB should describe how the other spec works. The way JAX-RS, Bean Val, JMS describe it makes more sense, IF CDI is available, these additional things occur. > > > > The probably is that CDI has already describe certain aspects about EJB. Because of that, its likely ours forever. > > > > The way most of these other services operate, it feels like they're all app server level integrations. So why wouldn't the entire EE ecosystem be described at the EE level? > > > > On Thu, Nov 12, 2015 at 5:46 AM Antoine Sabot-Durand wrote: > > From my POV problems are: > > > > - EJB spec totally ignore CDI (it's CDI that does all the job of EJB integration) > > - EJB spec won't be reopened except for minor MR > > - I launched the proposition for a new spec based on our AnnotatedType meta model when we were discussing about config spec. I didn't have enough support from Red Hat and EG so I put it back in my drawer. > > > > Antoine > > > > Le jeu. 12 nov. 2015 ? 11:17, Tomas Remes a ?crit : > > > > I think nothing will happen in EJB spec so I would not really rely on some future collaboration. Another case is this classpath scanning and AnnotatedType/PAT stuff. This sounds to me like quite interesting idea at least at first glance.:) But the question is: Isn't it late to propose any new JSR for upcoming EE 8? I guess it is so this seems to me bit out of scope for CDI 2.x... maybe CDI 3?:) > > > > Tom > > > > ----- Original Message ----- > > From: "Sven Linstaedt" > > To: "Romain Manni-Bucau" > > Cc: "cdi-dev" > > Sent: Thursday, November 12, 2015 10:45:22 AM > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > > > +1 for splitting the classpath scanning and all AnnotatedXXX / ProcessAnnotatedType type parsing/overriding from the CDI in an own spec, so other specs (not only EJB) may rely on it. > > > > 2015-11-11 20:54 GMT+01:00 Romain Manni-Bucau < rmannibucau at gmail.com > : > > > > > > > > Hi Mark, > > > > few points on that topic: > > > > - let the EJB container reuse AnnotatedType (ie even add @Stateless through an Extension): +1 > > - veto an EJB as a whole and not only in CDI side - ie @Schedule is ignored on EJB side of thing: I'm quite mitigated. Looks tempting but it would break the compatibility with extsing apps I fear since veto is 100% a CDI thing today. > > > > > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > > > > 2015-11-11 11:47 GMT-08:00 Mark Struberg < struberg at yahoo.de > : > > > > > > Hi! > > > > We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. > > > > E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. > > > > What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. > > The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. > > > > Any objections, any ideas, any howtos? > > > > Let the ideas roll ;) > > > > LieGrue, > > strub > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html ). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > -- > > Tomas Remes > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > From reza.rahman at oracle.com Mon Nov 16 17:40:33 2015 From: reza.rahman at oracle.com (Reza Rahman) Date: Mon, 16 Nov 2015 17:40:33 -0500 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: Message-ID: <564A5B61.1090808@oracle.com> In terms of CDI and EJB alignment, I think these would have the most value to the community going forward: * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has similarly nice syntax to handle eager loading). * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI. These are very useful bits of functionality that should be available to plain CDI beans without EJB. A similar @MaxConcurrency could also be extremely useful. EJB @Schedule is similarly useful but likely not right for CDI proper as it does not have that much to do with component life-cycle/bean access management. The others I think are quite natural fits for the core of a DI framework (in fact it may be awkward to have them elsewhere). As to doing more work in EJB, honestly it's likely best to leave EJB be at this stage. If there is a compelling reason that helps the platform and CDI generally we can see if it can be done. By default, EJB is pretty minimally resourced for Java EE 8 and that's pretty hard to change at this stage. In the community I have mostly seen requests for moving functionality out of EJB into CDI rather than the other way around... On 11/11/2015 2:47 PM, Mark Struberg wrote: > Hi! > > We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. > > E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. > > What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. > The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. > > Any objections, any ideas, any howtos? > > Let the ideas roll ;) > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From rmannibucau at gmail.com Mon Nov 16 17:44:12 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 Nov 2015 14:44:12 -0800 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: <564A5B61.1090808@oracle.com> References: <564A5B61.1090808@oracle.com> Message-ID: 2015-11-16 14:40 GMT-08:00 Reza Rahman : > In terms of CDI and EJB alignment, I think these would have the most > value to the community going forward: > > * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has > similarly nice syntax to handle eager loading). @Startup is there with @Initialized(ApplicationScoped) event @DependsOn is less important than for EJB IMO cause all CDI is lazy and full of proxies so not sure it would bring much to the game without bringing really much more like @Schedule etc... > * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI. > These are very useful bits of functionality that should be available to > plain CDI beans without EJB. A similar @MaxConcurrency could also be > extremely useful. EJB @Schedule is similarly useful but likely not right > for CDI proper as it does not have that much to do with component > life-cycle/bean access management. The others I think are quite natural > fits for the core of a DI framework (in fact it may be awkward to have > them elsewhere). Think concurrency utilities can have a CDI integration rather than putting everything in CDI. It is globally all interceptors - at least in term of design - so would make sense to have them outside IMO - but a big +1 to get them cleanly added on top of CDI. > > As to doing more work in EJB, honestly it's likely best to leave EJB be > at this stage. If there is a compelling reason that helps the platform > and CDI generally we can see if it can be done. By default, EJB is > pretty minimally resourced for Java EE 8 and that's pretty hard to > change at this stage. In the community I have mostly seen requests for > moving functionality out of EJB into CDI rather than the other way around... > > On 11/11/2015 2:47 PM, Mark Struberg wrote: >> Hi! >> >> We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. >> >> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >> >> What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. >> The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. >> >> Any objections, any ideas, any howtos? >> >> Let the ideas roll ;) >> >> LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From reza.rahman at oracle.com Mon Nov 16 17:54:25 2015 From: reza.rahman at oracle.com (Reza Rahman) Date: Mon, 16 Nov 2015 17:54:25 -0500 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <564A5B61.1090808@oracle.com> Message-ID: <81BFA4DB-F277-4F80-9698-DB99B51665FA@oracle.com> Responses in-line: > On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau wrote: > > 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> In terms of CDI and EJB alignment, I think these would have the most >> value to the community going forward: >> >> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >> similarly nice syntax to handle eager loading). > > @Startup is there with @Initialized(ApplicationScoped) event > @DependsOn is less important than for EJB IMO cause all CDI is lazy > and full of proxies so not sure it would bring much to the game > without bringing really much more like @Schedule etc... Yes, I know but eager loading is a common enough case to warrant better syntax/usability. > >> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI. >> These are very useful bits of functionality that should be available to >> plain CDI beans without EJB. A similar @MaxConcurrency could also be >> extremely useful. EJB @Schedule is similarly useful but likely not right >> for CDI proper as it does not have that much to do with component >> life-cycle/bean access management. The others I think are quite natural >> fits for the core of a DI framework (in fact it may be awkward to have >> them elsewhere). > > > Think concurrency utilities can have a CDI integration rather than > putting everything in CDI. It is globally all interceptors - at least > in term of design - so would make sense to have them outside IMO - but > a big +1 to get them cleanly added on top of CDI. Keep in mind, Java EE concurrency utilities is also minimally resourced and that's unlikely to change in the future. I would say if we think these features would help community/CDI adoption, it's likely wisest to find a way to do it in CDI proper. As I alluded to, these are also a bit easier to implement at the core DI container level than via interceptors. Things like @Transcational, @Schedule are easier as interceptors since they don't have as much to do with the internals of the component life-cycle and instance access control. > >> >> As to doing more work in EJB, honestly it's likely best to leave EJB be >> at this stage. If there is a compelling reason that helps the platform >> and CDI generally we can see if it can be done. By default, EJB is >> pretty minimally resourced for Java EE 8 and that's pretty hard to >> change at this stage. In the community I have mostly seen requests for >> moving functionality out of EJB into CDI rather than the other way around... >> >>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >>> Hi! >>> >>> We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. >>> >>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >>> >>> What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. >>> The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. >>> >>> Any objections, any ideas, any howtos? >>> >>> Let the ideas roll ;) >>> >>> LieGrue, >>> strub >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From rmannibucau at gmail.com Mon Nov 16 18:04:39 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 Nov 2015 15:04:39 -0800 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: <81BFA4DB-F277-4F80-9698-DB99B51665FA@oracle.com> References: <564A5B61.1090808@oracle.com> <81BFA4DB-F277-4F80-9698-DB99B51665FA@oracle.com> Message-ID: 2015-11-16 14:54 GMT-08:00 Reza Rahman : > Responses in-line: > >> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau wrote: >> >> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >>> In terms of CDI and EJB alignment, I think these would have the most >>> value to the community going forward: >>> >>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >>> similarly nice syntax to handle eager loading). >> >> @Startup is there with @Initialized(ApplicationScoped) event >> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> and full of proxies so not sure it would bring much to the game >> without bringing really much more like @Schedule etc... > > Yes, I know but eager loading is a common enough case to warrant better syntax/usability. > fair enough >> >>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI. >>> These are very useful bits of functionality that should be available to >>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >>> extremely useful. EJB @Schedule is similarly useful but likely not right >>> for CDI proper as it does not have that much to do with component >>> life-cycle/bean access management. The others I think are quite natural >>> fits for the core of a DI framework (in fact it may be awkward to have >>> them elsewhere). >> >> >> Think concurrency utilities can have a CDI integration rather than >> putting everything in CDI. It is globally all interceptors - at least >> in term of design - so would make sense to have them outside IMO - but >> a big +1 to get them cleanly added on top of CDI. > > Keep in mind, Java EE concurrency utilities is also minimally resourced and that's unlikely to change in the future. I would say if we think these features would help community/CDI adoption, it's likely wisest to find a way to do it in CDI proper. As I alluded to, these are also a bit easier to implement at the core DI container level than via interceptors. Things like @Transcational, @Schedule are easier as interceptors since they don't have as much to do with the internals of the component life-cycle and instance access control. > well yes and not, it would be awesome to control where the concurrency is exactly in the stack and it would mean being able to change @Priority for instance. Overall point being that if we put features only where resources are instead of trying to put them where they fit and try to help these specs CDI will likely handle javascript integration soon ;). Concurrency and throttling have a potential spec which would be welcomed in these very distributed days, we just need to find people motivated enough to make it moving forward IMO. >> >>> >>> As to doing more work in EJB, honestly it's likely best to leave EJB be >>> at this stage. If there is a compelling reason that helps the platform >>> and CDI generally we can see if it can be done. By default, EJB is >>> pretty minimally resourced for Java EE 8 and that's pretty hard to >>> change at this stage. In the community I have mostly seen requests for >>> moving functionality out of EJB into CDI rather than the other way around... >>> >>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >>>> Hi! >>>> >>>> We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. >>>> >>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >>>> >>>> What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. >>>> The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. >>>> >>>> Any objections, any ideas, any howtos? >>>> >>>> Let the ideas roll ;) >>>> >>>> LieGrue, >>>> strub >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From reza.rahman at oracle.com Mon Nov 16 18:55:04 2015 From: reza.rahman at oracle.com (Reza Rahman) Date: Mon, 16 Nov 2015 18:55:04 -0500 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <564A5B61.1090808@oracle.com> <81BFA4DB-F277-4F80-9698-DB99B51665FA@oracle.com> Message-ID: One good thing is that Oracle has not yet filed a JSR for Java EE concurrency utilities targeting Java EE 8. That means any interested parties could do so and perhaps that could be better for the community in the end anyway. Certainly starting prototyping some of these things will make it clearer where they belong or could be contributed to in the end. > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau wrote: > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> Responses in-line: >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau wrote: >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >>>> In terms of CDI and EJB alignment, I think these would have the most >>>> value to the community going forward: >>>> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >>>> similarly nice syntax to handle eager loading). >>> >>> @Startup is there with @Initialized(ApplicationScoped) event >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >>> and full of proxies so not sure it would bring much to the game >>> without bringing really much more like @Schedule etc... >> >> Yes, I know but eager loading is a common enough case to warrant better syntax/usability. > > fair enough > >>> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI. >>>> These are very useful bits of functionality that should be available to >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >>>> extremely useful. EJB @Schedule is similarly useful but likely not right >>>> for CDI proper as it does not have that much to do with component >>>> life-cycle/bean access management. The others I think are quite natural >>>> fits for the core of a DI framework (in fact it may be awkward to have >>>> them elsewhere). >>> >>> >>> Think concurrency utilities can have a CDI integration rather than >>> putting everything in CDI. It is globally all interceptors - at least >>> in term of design - so would make sense to have them outside IMO - but >>> a big +1 to get them cleanly added on top of CDI. >> >> Keep in mind, Java EE concurrency utilities is also minimally resourced and that's unlikely to change in the future. I would say if we think these features would help community/CDI adoption, it's likely wisest to find a way to do it in CDI proper. As I alluded to, these are also a bit easier to implement at the core DI container level than via interceptors. Things like @Transcational, @Schedule are easier as interceptors since they don't have as much to do with the internals of the component life-cycle and instance access control. > > well yes and not, it would be awesome to control where the concurrency > is exactly in the stack and it would mean being able to change > @Priority for instance. > > Overall point being that if we put features only where resources are > instead of trying to put them where they fit and try to help these > specs CDI will likely handle javascript integration soon ;). > > Concurrency and throttling have a potential spec which would be > welcomed in these very distributed days, we just need to find people > motivated enough to make it moving forward IMO. > >>> >>>> >>>> As to doing more work in EJB, honestly it's likely best to leave EJB be >>>> at this stage. If there is a compelling reason that helps the platform >>>> and CDI generally we can see if it can be done. By default, EJB is >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >>>> change at this stage. In the community I have mostly seen requests for >>>> moving functionality out of EJB into CDI rather than the other way around... >>>> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >>>>> Hi! >>>>> >>>>> We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. >>>>> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >>>>> >>>>> What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. >>>>> The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. >>>>> >>>>> Any objections, any ideas, any howtos? >>>>> >>>>> Let the ideas roll ;) >>>>> >>>>> LieGrue, >>>>> strub >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From antonio.goncalves at gmail.com Tue Nov 17 08:44:35 2015 From: antonio.goncalves at gmail.com (Antonio Goncalves) Date: Tue, 17 Nov 2015 14:44:35 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <564A5B61.1090808@oracle.com> <81BFA4DB-F277-4F80-9698-DB99B51665FA@oracle.com> Message-ID: HI all, This discussion comes back on and off. At the last F2F meeting, we talked about having @Startup and @Shutdown in JSR 250. Talking to Bill and Linda, they don't seem reluctant to update the spec. No need to have @DependsOn as we will use @Priority with @Startup. @Schedule should go to Java EE Concurrency (implemented as a CDI interceptor) but not in CDI as this would be just moving more stuff inside CDI (which will end up as big as EJBs). Same for @Asynchronous. So what could be doable in CDI 2.1 is having @Startup and @Shutdown implemented... but the annotations would be in JSR 250. Antonio On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman wrote: > One good thing is that Oracle has not yet filed a JSR for Java EE > concurrency utilities targeting Java EE 8. That means any interested > parties could do so and perhaps that could be better for the community in > the end anyway. > > Certainly starting prototyping some of these things will make it clearer > where they belong or could be contributed to in the end. > > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau > wrote: > > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > >> Responses in-line: > >> > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau > wrote: > >>> > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > >>>> In terms of CDI and EJB alignment, I think these would have the most > >>>> value to the community going forward: > >>>> > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has > >>>> similarly nice syntax to handle eager loading). > >>> > >>> @Startup is there with @Initialized(ApplicationScoped) event > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy > >>> and full of proxies so not sure it would bring much to the game > >>> without bringing really much more like @Schedule etc... > >> > >> Yes, I know but eager loading is a common enough case to warrant better > syntax/usability. > > > > fair enough > > > >>> > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for > CDI. > >>>> These are very useful bits of functionality that should be available > to > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be > >>>> extremely useful. EJB @Schedule is similarly useful but likely not > right > >>>> for CDI proper as it does not have that much to do with component > >>>> life-cycle/bean access management. The others I think are quite > natural > >>>> fits for the core of a DI framework (in fact it may be awkward to have > >>>> them elsewhere). > >>> > >>> > >>> Think concurrency utilities can have a CDI integration rather than > >>> putting everything in CDI. It is globally all interceptors - at least > >>> in term of design - so would make sense to have them outside IMO - but > >>> a big +1 to get them cleanly added on top of CDI. > >> > >> Keep in mind, Java EE concurrency utilities is also minimally resourced > and that's unlikely to change in the future. I would say if we think these > features would help community/CDI adoption, it's likely wisest to find a > way to do it in CDI proper. As I alluded to, these are also a bit easier to > implement at the core DI container level than via interceptors. Things like > @Transcational, @Schedule are easier as interceptors since they don't have > as much to do with the internals of the component life-cycle and instance > access control. > > > > well yes and not, it would be awesome to control where the concurrency > > is exactly in the stack and it would mean being able to change > > @Priority for instance. > > > > Overall point being that if we put features only where resources are > > instead of trying to put them where they fit and try to help these > > specs CDI will likely handle javascript integration soon ;). > > > > Concurrency and throttling have a potential spec which would be > > welcomed in these very distributed days, we just need to find people > > motivated enough to make it moving forward IMO. > > > >>> > >>>> > >>>> As to doing more work in EJB, honestly it's likely best to leave EJB > be > >>>> at this stage. If there is a compelling reason that helps the platform > >>>> and CDI generally we can see if it can be done. By default, EJB is > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to > >>>> change at this stage. In the community I have mostly seen requests for > >>>> moving functionality out of EJB into CDI rather than the other way > around... > >>>> > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > >>>>> Hi! > >>>>> > >>>>> We already do a decent amount of ?side-by-side? handling in EJB and > CDI. But there are still many aready where we could really move together > much closer. > >>>>> > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by > the EJB container. But what happens with ProcessAnnotatedType#veto(). This > one is not defined that clearly I fear. > >>>>> > >>>>> What if we (of course together with the EJB spec group) define that > the EJB container must create the EJBs according to the effective > AnnotatedType coming out after ProcessAnnotatedType? This would define that > EJBs can also get modified via CDI Extensions. Some container do that > already. > >>>>> The benefit of explicitly writing this down would obviously be that > we would allow EJB to fully utilize the power of CDI Extensions in a > portable way. > >>>>> > >>>>> Any objections, any ideas, any howtos? > >>>>> > >>>>> Let the ideas roll ;) > >>>>> > >>>>> LieGrue, > >>>>> strub > >>>>> _______________________________________________ > >>>>> cdi-dev mailing list > >>>>> cdi-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> > >>>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/attachment.html From arjan.tijms at gmail.com Tue Nov 17 09:03:32 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 17 Nov 2015 15:03:32 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <564A5B61.1090808@oracle.com> <81BFA4DB-F277-4F80-9698-DB99B51665FA@oracle.com> Message-ID: Hi, On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < antonio.goncalves at gmail.com> wrote: > @Schedule should go to Java EE Concurrency (implemented as a CDI > interceptor) but not in CDI as this would be just moving more stuff inside > CDI (which will end up as big as EJBs). Same for @Asynchronous. > 100% agree with this. It's almost better not to do things if absolutely needed, then burden CDI with some concerns it perhaps should not be concerned with. It's already problematic that CDI crossed this bridge once with providing a Bean for Servlet and other artifacts it doesn't own. As for @Asynchronous, a basic prototype implementation has already been created by several parties. I did one here: http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld team did one here: https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java Also interesting would be to go a little beyond what the EJB vesion offers and add support for a completable feature and optionally named thread pools. Kind regards, Arjan Tijms > > So what could be doable in CDI 2.1 is having @Startup and @Shutdown > implemented... but the annotations would be in JSR 250. > > Antonio > > > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman > wrote: > >> One good thing is that Oracle has not yet filed a JSR for Java EE >> concurrency utilities targeting Java EE 8. That means any interested >> parties could do so and perhaps that could be better for the community in >> the end anyway. >> >> Certainly starting prototyping some of these things will make it clearer >> where they belong or could be contributed to in the end. >> >> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau >> wrote: >> > >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> >> Responses in-line: >> >> >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>> >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> >>>> In terms of CDI and EJB alignment, I think these would have the most >> >>>> value to the community going forward: >> >>>> >> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >> >>>> similarly nice syntax to handle eager loading). >> >>> >> >>> @Startup is there with @Initialized(ApplicationScoped) event >> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> >>> and full of proxies so not sure it would bring much to the game >> >>> without bringing really much more like @Schedule etc... >> >> >> >> Yes, I know but eager loading is a common enough case to warrant >> better syntax/usability. >> > >> > fair enough >> > >> >>> >> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for >> CDI. >> >>>> These are very useful bits of functionality that should be available >> to >> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >> >>>> extremely useful. EJB @Schedule is similarly useful but likely not >> right >> >>>> for CDI proper as it does not have that much to do with component >> >>>> life-cycle/bean access management. The others I think are quite >> natural >> >>>> fits for the core of a DI framework (in fact it may be awkward to >> have >> >>>> them elsewhere). >> >>> >> >>> >> >>> Think concurrency utilities can have a CDI integration rather than >> >>> putting everything in CDI. It is globally all interceptors - at least >> >>> in term of design - so would make sense to have them outside IMO - but >> >>> a big +1 to get them cleanly added on top of CDI. >> >> >> >> Keep in mind, Java EE concurrency utilities is also minimally >> resourced and that's unlikely to change in the future. I would say if we >> think these features would help community/CDI adoption, it's likely wisest >> to find a way to do it in CDI proper. As I alluded to, these are also a bit >> easier to implement at the core DI container level than via interceptors. >> Things like @Transcational, @Schedule are easier as interceptors since they >> don't have as much to do with the internals of the component life-cycle and >> instance access control. >> > >> > well yes and not, it would be awesome to control where the concurrency >> > is exactly in the stack and it would mean being able to change >> > @Priority for instance. >> > >> > Overall point being that if we put features only where resources are >> > instead of trying to put them where they fit and try to help these >> > specs CDI will likely handle javascript integration soon ;). >> > >> > Concurrency and throttling have a potential spec which would be >> > welcomed in these very distributed days, we just need to find people >> > motivated enough to make it moving forward IMO. >> > >> >>> >> >>>> >> >>>> As to doing more work in EJB, honestly it's likely best to leave EJB >> be >> >>>> at this stage. If there is a compelling reason that helps the >> platform >> >>>> and CDI generally we can see if it can be done. By default, EJB is >> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >> >>>> change at this stage. In the community I have mostly seen requests >> for >> >>>> moving functionality out of EJB into CDI rather than the other way >> around... >> >>>> >> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> >>>>> Hi! >> >>>>> >> >>>>> We already do a decent amount of ?side-by-side? handling in EJB and >> CDI. But there are still many aready where we could really move together >> much closer. >> >>>>> >> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted >> by the EJB container. But what happens with ProcessAnnotatedType#veto(). >> This one is not defined that clearly I fear. >> >>>>> >> >>>>> What if we (of course together with the EJB spec group) define that >> the EJB container must create the EJBs according to the effective >> AnnotatedType coming out after ProcessAnnotatedType? This would define that >> EJBs can also get modified via CDI Extensions. Some container do that >> already. >> >>>>> The benefit of explicitly writing this down would obviously be that >> we would allow EJB to fully utilize the power of CDI Extensions in a >> portable way. >> >>>>> >> >>>>> Any objections, any ideas, any howtos? >> >>>>> >> >>>>> Let the ideas roll ;) >> >>>>> >> >>>>> LieGrue, >> >>>>> strub >> >>>>> _______________________________________________ >> >>>>> cdi-dev mailing list >> >>>>> cdi-dev at lists.jboss.org >> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>> >> >>>>> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn > | Pluralsight > | Paris > JUG | Devoxx France > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/c074f5ae/attachment-0001.html From werner.keil at gmail.com Tue Nov 17 09:17:58 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 17 Nov 2015 15:17:58 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB Message-ID: Reza/all, Do you suggest, others could/should take over as Spec Lead of a new Java EE Concurrency JSR or just gather ideas and do brainstorming, similar to e.g. what happens in JSR 375? Werner On Tue, Nov 17, 2015 at 1:37 PM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) > 2. Re: [PROPOSAL] further align CDI and EJB (Antonio Goncalves) > 3. Re: [PROPOSAL] further align CDI and EJB (arjan tijms) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Nov 2015 18:55:04 -0500 > From: Reza Rahman > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > To: "cdi-dev at lists.jboss.org" > Message-ID: > Content-Type: text/plain; charset=utf-8 > > One good thing is that Oracle has not yet filed a JSR for Java EE > concurrency utilities targeting Java EE 8. That means any interested > parties could do so and perhaps that could be better for the community in > the end anyway. > > Certainly starting prototyping some of these things will make it clearer > where they belong or could be contributed to in the end. > > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau > wrote: > > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > >> Responses in-line: > >> > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau > wrote: > >>> > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > >>>> In terms of CDI and EJB alignment, I think these would have the most > >>>> value to the community going forward: > >>>> > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has > >>>> similarly nice syntax to handle eager loading). > >>> > >>> @Startup is there with @Initialized(ApplicationScoped) event > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy > >>> and full of proxies so not sure it would bring much to the game > >>> without bringing really much more like @Schedule etc... > >> > >> Yes, I know but eager loading is a common enough case to warrant better > syntax/usability. > > > > fair enough > > > >>> > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for > CDI. > >>>> These are very useful bits of functionality that should be available > to > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be > >>>> extremely useful. EJB @Schedule is similarly useful but likely not > right > >>>> for CDI proper as it does not have that much to do with component > >>>> life-cycle/bean access management. The others I think are quite > natural > >>>> fits for the core of a DI framework (in fact it may be awkward to have > >>>> them elsewhere). > >>> > >>> > >>> Think concurrency utilities can have a CDI integration rather than > >>> putting everything in CDI. It is globally all interceptors - at least > >>> in term of design - so would make sense to have them outside IMO - but > >>> a big +1 to get them cleanly added on top of CDI. > >> > >> Keep in mind, Java EE concurrency utilities is also minimally resourced > and that's unlikely to change in the future. I would say if we think these > features would help community/CDI adoption, it's likely wisest to find a > way to do it in CDI proper. As I alluded to, these are also a bit easier to > implement at the core DI container level than via interceptors. Things like > @Transcational, @Schedule are easier as interceptors since they don't have > as much to do with the internals of the component life-cycle and instance > access control. > > > > well yes and not, it would be awesome to control where the concurrency > > is exactly in the stack and it would mean being able to change > > @Priority for instance. > > > > Overall point being that if we put features only where resources are > > instead of trying to put them where they fit and try to help these > > specs CDI will likely handle javascript integration soon ;). > > > > Concurrency and throttling have a potential spec which would be > > welcomed in these very distributed days, we just need to find people > > motivated enough to make it moving forward IMO. > > > >>> > >>>> > >>>> As to doing more work in EJB, honestly it's likely best to leave EJB > be > >>>> at this stage. If there is a compelling reason that helps the platform > >>>> and CDI generally we can see if it can be done. By default, EJB is > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to > >>>> change at this stage. In the community I have mostly seen requests for > >>>> moving functionality out of EJB into CDI rather than the other way > around... > >>>> > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > >>>>> Hi! > >>>>> > >>>>> We already do a decent amount of ?side-by-side? handling in EJB and > CDI. But there are still many aready where we could really move together > much closer. > >>>>> > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by > the EJB container. But what happens with ProcessAnnotatedType#veto(). This > one is not defined that clearly I fear. > >>>>> > >>>>> What if we (of course together with the EJB spec group) define that > the EJB container must create the EJBs according to the effective > AnnotatedType coming out after ProcessAnnotatedType? This would define that > EJBs can also get modified via CDI Extensions. Some container do that > already. > >>>>> The benefit of explicitly writing this down would obviously be that > we would allow EJB to fully utilize the power of CDI Extensions in a > portable way. > >>>>> > >>>>> Any objections, any ideas, any howtos? > >>>>> > >>>>> Let the ideas roll ;) > >>>>> > >>>>> LieGrue, > >>>>> strub > >>>>> _______________________________________________ > >>>>> cdi-dev mailing list > >>>>> cdi-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> > >>>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>>> > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > ------------------------------ > > Message: 2 > Date: Tue, 17 Nov 2015 14:44:35 +0100 > From: Antonio Goncalves > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > To: Reza Rahman > Cc: "cdi-dev at lists.jboss.org" > Message-ID: > < > CA+ZZq98nGkMYUj5uEt7UuGHFcttdoi7zTiH_mWK5n_9zy2EaNQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > HI all, > > This discussion comes back on and off. > > At the last F2F meeting, we talked about having @Startup and @Shutdown in > JSR 250. Talking to Bill and Linda, they don't seem reluctant to update the > spec. No need to have @DependsOn as we will use @Priority with @Startup. > > @Schedule should go to Java EE Concurrency (implemented as a CDI > interceptor) but not in CDI as this would be just moving more stuff inside > CDI (which will end up as big as EJBs). Same for @Asynchronous. > > So what could be doable in CDI 2.1 is having @Startup and @Shutdown > implemented... but the annotations would be in JSR 250. > > Antonio > > > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman > wrote: > > > One good thing is that Oracle has not yet filed a JSR for Java EE > > concurrency utilities targeting Java EE 8. That means any interested > > parties could do so and perhaps that could be better for the community in > > the end anyway. > > > > Certainly starting prototyping some of these things will make it clearer > > where they belong or could be contributed to in the end. > > > > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau > > > wrote: > > > > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > > >> Responses in-line: > > >> > > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> > > wrote: > > >>> > > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > > >>>> In terms of CDI and EJB alignment, I think these would have the most > > >>>> value to the community going forward: > > >>>> > > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has > > >>>> similarly nice syntax to handle eager loading). > > >>> > > >>> @Startup is there with @Initialized(ApplicationScoped) event > > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy > > >>> and full of proxies so not sure it would bring much to the game > > >>> without bringing really much more like @Schedule etc... > > >> > > >> Yes, I know but eager loading is a common enough case to warrant > better > > syntax/usability. > > > > > > fair enough > > > > > >>> > > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for > > CDI. > > >>>> These are very useful bits of functionality that should be available > > to > > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be > > >>>> extremely useful. EJB @Schedule is similarly useful but likely not > > right > > >>>> for CDI proper as it does not have that much to do with component > > >>>> life-cycle/bean access management. The others I think are quite > > natural > > >>>> fits for the core of a DI framework (in fact it may be awkward to > have > > >>>> them elsewhere). > > >>> > > >>> > > >>> Think concurrency utilities can have a CDI integration rather than > > >>> putting everything in CDI. It is globally all interceptors - at least > > >>> in term of design - so would make sense to have them outside IMO - > but > > >>> a big +1 to get them cleanly added on top of CDI. > > >> > > >> Keep in mind, Java EE concurrency utilities is also minimally > resourced > > and that's unlikely to change in the future. I would say if we think > these > > features would help community/CDI adoption, it's likely wisest to find a > > way to do it in CDI proper. As I alluded to, these are also a bit easier > to > > implement at the core DI container level than via interceptors. Things > like > > @Transcational, @Schedule are easier as interceptors since they don't > have > > as much to do with the internals of the component life-cycle and instance > > access control. > > > > > > well yes and not, it would be awesome to control where the concurrency > > > is exactly in the stack and it would mean being able to change > > > @Priority for instance. > > > > > > Overall point being that if we put features only where resources are > > > instead of trying to put them where they fit and try to help these > > > specs CDI will likely handle javascript integration soon ;). > > > > > > Concurrency and throttling have a potential spec which would be > > > welcomed in these very distributed days, we just need to find people > > > motivated enough to make it moving forward IMO. > > > > > >>> > > >>>> > > >>>> As to doing more work in EJB, honestly it's likely best to leave EJB > > be > > >>>> at this stage. If there is a compelling reason that helps the > platform > > >>>> and CDI generally we can see if it can be done. By default, EJB is > > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to > > >>>> change at this stage. In the community I have mostly seen requests > for > > >>>> moving functionality out of EJB into CDI rather than the other way > > around... > > >>>> > > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > > >>>>> Hi! > > >>>>> > > >>>>> We already do a decent amount of ?side-by-side? handling in EJB and > > CDI. But there are still many aready where we could really move together > > much closer. > > >>>>> > > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted > by > > the EJB container. But what happens with ProcessAnnotatedType#veto(). > This > > one is not defined that clearly I fear. > > >>>>> > > >>>>> What if we (of course together with the EJB spec group) define that > > the EJB container must create the EJBs according to the effective > > AnnotatedType coming out after ProcessAnnotatedType? This would define > that > > EJBs can also get modified via CDI Extensions. Some container do that > > already. > > >>>>> The benefit of explicitly writing this down would obviously be that > > we would allow EJB to fully utilize the power of CDI Extensions in a > > portable way. > > >>>>> > > >>>>> Any objections, any ideas, any howtos? > > >>>>> > > >>>>> Let the ideas roll ;) > > >>>>> > > >>>>> LieGrue, > > >>>>> strub > > >>>>> _______________________________________________ > > >>>>> cdi-dev mailing list > > >>>>> cdi-dev at lists.jboss.org > > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >>>>> > > >>>>> Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > >>>> > > >>>> _______________________________________________ > > >>>> cdi-dev mailing list > > >>>> cdi-dev at lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >>>> > > >>>> Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > > > -- > Antonio Goncalves > Software architect, Java Champion and Pluralsight author > > Web site | Twitter > | LinkedIn < > http://www.linkedin.com/in/agoncal> | > Pluralsight > | > Paris > JUG | Devoxx France > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Tue, 17 Nov 2015 15:03:32 +0100 > From: arjan tijms > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > To: Antonio Goncalves > Cc: "cdi-dev at lists.jboss.org" > Message-ID: > AhAhn2W-yvJgGHQdv7PNS2jjGbJouxNirYOKyekuy9s3mQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > > > @Schedule should go to Java EE Concurrency (implemented as a CDI > > interceptor) but not in CDI as this would be just moving more stuff > inside > > CDI (which will end up as big as EJBs). Same for @Asynchronous. > > > > 100% agree with this. It's almost better not to do things if absolutely > needed, then burden CDI with some concerns it perhaps should not be > concerned with. It's already problematic that CDI crossed this bridge once > with providing a Bean for Servlet and other artifacts it doesn't own. > > As for @Asynchronous, a basic prototype implementation has already been > created by several parties. I did one here: > http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld > team > did one here: > > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java > > Also interesting would be to go a little beyond what the EJB vesion offers > and add support for a completable feature and optionally named thread > pools. > > Kind regards, > Arjan Tijms > > > > > > > > So what could be doable in CDI 2.1 is having @Startup and @Shutdown > > implemented... but the annotations would be in JSR 250. > > > > Antonio > > > > > > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman > > wrote: > > > >> One good thing is that Oracle has not yet filed a JSR for Java EE > >> concurrency utilities targeting Java EE 8. That means any interested > >> parties could do so and perhaps that could be better for the community > in > >> the end anyway. > >> > >> Certainly starting prototyping some of these things will make it clearer > >> where they belong or could be contributed to in the end. > >> > >> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> > >> wrote: > >> > > >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > >> >> Responses in-line: > >> >> > >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < > >> rmannibucau at gmail.com> wrote: > >> >>> > >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > >> >>>> In terms of CDI and EJB alignment, I think these would have the > most > >> >>>> value to the community going forward: > >> >>>> > >> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core > has > >> >>>> similarly nice syntax to handle eager loading). > >> >>> > >> >>> @Startup is there with @Initialized(ApplicationScoped) event > >> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy > >> >>> and full of proxies so not sure it would bring much to the game > >> >>> without bringing really much more like @Schedule etc... > >> >> > >> >> Yes, I know but eager loading is a common enough case to warrant > >> better syntax/usability. > >> > > >> > fair enough > >> > > >> >>> > >> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for > >> CDI. > >> >>>> These are very useful bits of functionality that should be > available > >> to > >> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also > be > >> >>>> extremely useful. EJB @Schedule is similarly useful but likely not > >> right > >> >>>> for CDI proper as it does not have that much to do with component > >> >>>> life-cycle/bean access management. The others I think are quite > >> natural > >> >>>> fits for the core of a DI framework (in fact it may be awkward to > >> have > >> >>>> them elsewhere). > >> >>> > >> >>> > >> >>> Think concurrency utilities can have a CDI integration rather than > >> >>> putting everything in CDI. It is globally all interceptors - at > least > >> >>> in term of design - so would make sense to have them outside IMO - > but > >> >>> a big +1 to get them cleanly added on top of CDI. > >> >> > >> >> Keep in mind, Java EE concurrency utilities is also minimally > >> resourced and that's unlikely to change in the future. I would say if we > >> think these features would help community/CDI adoption, it's likely > wisest > >> to find a way to do it in CDI proper. As I alluded to, these are also a > bit > >> easier to implement at the core DI container level than via > interceptors. > >> Things like @Transcational, @Schedule are easier as interceptors since > they > >> don't have as much to do with the internals of the component life-cycle > and > >> instance access control. > >> > > >> > well yes and not, it would be awesome to control where the concurrency > >> > is exactly in the stack and it would mean being able to change > >> > @Priority for instance. > >> > > >> > Overall point being that if we put features only where resources are > >> > instead of trying to put them where they fit and try to help these > >> > specs CDI will likely handle javascript integration soon ;). > >> > > >> > Concurrency and throttling have a potential spec which would be > >> > welcomed in these very distributed days, we just need to find people > >> > motivated enough to make it moving forward IMO. > >> > > >> >>> > >> >>>> > >> >>>> As to doing more work in EJB, honestly it's likely best to leave > EJB > >> be > >> >>>> at this stage. If there is a compelling reason that helps the > >> platform > >> >>>> and CDI generally we can see if it can be done. By default, EJB is > >> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to > >> >>>> change at this stage. In the community I have mostly seen requests > >> for > >> >>>> moving functionality out of EJB into CDI rather than the other way > >> around... > >> >>>> > >> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > >> >>>>> Hi! > >> >>>>> > >> >>>>> We already do a decent amount of ?side-by-side? handling in EJB > and > >> CDI. But there are still many aready where we could really move together > >> much closer. > >> >>>>> > >> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted > >> by the EJB container. But what happens with ProcessAnnotatedType#veto(). > >> This one is not defined that clearly I fear. > >> >>>>> > >> >>>>> What if we (of course together with the EJB spec group) define > that > >> the EJB container must create the EJBs according to the effective > >> AnnotatedType coming out after ProcessAnnotatedType? This would define > that > >> EJBs can also get modified via CDI Extensions. Some container do that > >> already. > >> >>>>> The benefit of explicitly writing this down would obviously be > that > >> we would allow EJB to fully utilize the power of CDI Extensions in a > >> portable way. > >> >>>>> > >> >>>>> Any objections, any ideas, any howtos? > >> >>>>> > >> >>>>> Let the ideas roll ;) > >> >>>>> > >> >>>>> LieGrue, > >> >>>>> strub > >> >>>>> _______________________________________________ > >> >>>>> cdi-dev mailing list > >> >>>>> cdi-dev at lists.jboss.org > >> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >>>>> > >> >>>>> Note that for all code provided on this list, the provider > licenses > >> the code under the Apache License, Version 2 ( > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other > >> intellectual property rights inherent in such information. > >> >>>> > >> >>>> _______________________________________________ > >> >>>> cdi-dev mailing list > >> >>>> cdi-dev at lists.jboss.org > >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> >>>> > >> >>>> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 ( > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other > >> intellectual property rights inherent in such information. > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > >> code under the Apache License, Version 2 ( > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other > >> intellectual property rights inherent in such information. > >> > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter > > | LinkedIn > > | Pluralsight > > | > Paris > > JUG | Devoxx France > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/c074f5ae/attachment.html > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > End of cdi-dev Digest, Vol 60, Issue 13 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/b1fb79c2/attachment-0001.html From reza.rahman at oracle.com Tue Nov 17 09:24:31 2015 From: reza.rahman at oracle.com (Reza Rahman) Date: Tue, 17 Nov 2015 09:24:31 -0500 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: <564A5B61.1090808@oracle.com> <81BFA4DB-F277-4F80-9698-DB99B51665FA@oracle.com> Message-ID: <39F78EFC-0E6D-4AAA-B81B-BF00DF9FBD74@oracle.com> I would encourage finding a way to contribute this work to a Java EE specification (CDI or otherwise) while being aware of the resource realities. It does not necessarily need to be done in the short term since Java EE does have something after all from a purely functional standpoint. Adding completable future to @Asynchronous is definitely an obvious improvement at this stage. I am trying to get that done for EJB if I at all can. I think a contribution in the GF 5 branch accomplishing that in EJB would be incredibly beneficial if time permits. I could then take care of the TCK and spec text portions. > On Nov 17, 2015, at 9:03 AM, arjan tijms wrote: > > Hi, > >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves wrote: >> @Schedule should go to Java EE Concurrency (implemented as a CDI interceptor) but not in CDI as this would be just moving more stuff inside CDI (which will end up as big as EJBs). Same for @Asynchronous. > > 100% agree with this. It's almost better not to do things if absolutely needed, then burden CDI with some concerns it perhaps should not be concerned with. It's already problematic that CDI crossed this bridge once with providing a Bean for Servlet and other artifacts it doesn't own. > > As for @Asynchronous, a basic prototype implementation has already been created by several parties. I did one here: http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld team did one here: https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java > > Also interesting would be to go a little beyond what the EJB vesion offers and add support for a completable feature and optionally named thread pools. > > Kind regards, > Arjan Tijms > > > >> >> So what could be doable in CDI 2.1 is having @Startup and @Shutdown implemented... but the annotations would be in JSR 250. >> >> Antonio >> >> >>> On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman wrote: >>> One good thing is that Oracle has not yet filed a JSR for Java EE concurrency utilities targeting Java EE 8. That means any interested parties could do so and perhaps that could be better for the community in the end anyway. >>> >>> Certainly starting prototyping some of these things will make it clearer where they belong or could be contributed to in the end. >>> >>> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau wrote: >>> > >>> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >>> >> Responses in-line: >>> >> >>> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau wrote: >>> >>> >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >>> >>>> In terms of CDI and EJB alignment, I think these would have the most >>> >>>> value to the community going forward: >>> >>>> >>> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >>> >>>> similarly nice syntax to handle eager loading). >>> >>> >>> >>> @Startup is there with @Initialized(ApplicationScoped) event >>> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >>> >>> and full of proxies so not sure it would bring much to the game >>> >>> without bringing really much more like @Schedule etc... >>> >> >>> >> Yes, I know but eager loading is a common enough case to warrant better syntax/usability. >>> > >>> > fair enough >>> > >>> >>> >>> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI. >>> >>>> These are very useful bits of functionality that should be available to >>> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >>> >>>> extremely useful. EJB @Schedule is similarly useful but likely not right >>> >>>> for CDI proper as it does not have that much to do with component >>> >>>> life-cycle/bean access management. The others I think are quite natural >>> >>>> fits for the core of a DI framework (in fact it may be awkward to have >>> >>>> them elsewhere). >>> >>> >>> >>> >>> >>> Think concurrency utilities can have a CDI integration rather than >>> >>> putting everything in CDI. It is globally all interceptors - at least >>> >>> in term of design - so would make sense to have them outside IMO - but >>> >>> a big +1 to get them cleanly added on top of CDI. >>> >> >>> >> Keep in mind, Java EE concurrency utilities is also minimally resourced and that's unlikely to change in the future. I would say if we think these features would help community/CDI adoption, it's likely wisest to find a way to do it in CDI proper. As I alluded to, these are also a bit easier to implement at the core DI container level than via interceptors. Things like @Transcational, @Schedule are easier as interceptors since they don't have as much to do with the internals of the component life-cycle and instance access control. >>> > >>> > well yes and not, it would be awesome to control where the concurrency >>> > is exactly in the stack and it would mean being able to change >>> > @Priority for instance. >>> > >>> > Overall point being that if we put features only where resources are >>> > instead of trying to put them where they fit and try to help these >>> > specs CDI will likely handle javascript integration soon ;). >>> > >>> > Concurrency and throttling have a potential spec which would be >>> > welcomed in these very distributed days, we just need to find people >>> > motivated enough to make it moving forward IMO. >>> > >>> >>> >>> >>>> >>> >>>> As to doing more work in EJB, honestly it's likely best to leave EJB be >>> >>>> at this stage. If there is a compelling reason that helps the platform >>> >>>> and CDI generally we can see if it can be done. By default, EJB is >>> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >>> >>>> change at this stage. In the community I have mostly seen requests for >>> >>>> moving functionality out of EJB into CDI rather than the other way around... >>> >>>> >>> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >>> >>>>> Hi! >>> >>>>> >>> >>>>> We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. >>> >>>>> >>> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >>> >>>>> >>> >>>>> What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. >>> >>>>> The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. >>> >>>>> >>> >>>>> Any objections, any ideas, any howtos? >>> >>>>> >>> >>>>> Let the ideas roll ;) >>> >>>>> >>> >>>>> LieGrue, >>> >>>>> strub >>> >>>>> _______________________________________________ >>> >>>>> cdi-dev mailing list >>> >>>>> cdi-dev at lists.jboss.org >>> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>>> >>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>>> >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev at lists.jboss.org >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>> >>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/98382c30/attachment.html From werner.keil at gmail.com Tue Nov 17 09:25:22 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 17 Nov 2015 15:25:22 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB Message-ID: Looking at the EG of JSR 236 however, other than 2 JCP Award winners in the member category (Doug Lea and Adam Bien, the latter did however admit when he picked his award, he wasn't sure who nominated him, and that at least when it comes to active involvement in JSRs he was far from active in any of them;-) there are pretty much the "Big 3" IBM, Oracle Red Hat (in alphabetical order) only in that EG. So should Oracle prefer someone took the Spec Lead role for Java EE Concurrency.next, who other than those Big 3 would be a suitable Spec Lead or Co Spec Lead? I know what it means, since I am also Spec Lead of an active JSR, but that is more than enough until that's gone final. Sure, there are other Individual or corporate members in this and other EE EGs who might be a good fit for that aside from say the obvious Doug Lea;-) Werner On Tue, Nov 17, 2015 at 1:51 PM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Re: [PROPOSAL] further align CDI and EJB (Werner Keil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 17 Nov 2015 15:17:58 +0100 > From: Werner Keil > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > To: cdi-dev > Message-ID: > < > CAAGawe1FFg7bJazj67gpXXEKBJ8Qu+v9yAxECaEdmgoTr2-hHQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Reza/all, > > Do you suggest, others could/should take over as Spec Lead of a new Java EE > Concurrency JSR or just gather ideas and do brainstorming, similar to e.g. > what happens in JSR 375? > > Werner > > > > On Tue, Nov 17, 2015 at 1:37 PM, wrote: > > > Send cdi-dev mailing list submissions to > > cdi-dev at lists.jboss.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > or, via email, send a message with subject or body 'help' to > > cdi-dev-request at lists.jboss.org > > > > You can reach the person managing the list at > > cdi-dev-owner at lists.jboss.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of cdi-dev digest..." > > > > > > Today's Topics: > > > > 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) > > 2. Re: [PROPOSAL] further align CDI and EJB (Antonio Goncalves) > > 3. Re: [PROPOSAL] further align CDI and EJB (arjan tijms) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 16 Nov 2015 18:55:04 -0500 > > From: Reza Rahman > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > To: "cdi-dev at lists.jboss.org" > > Message-ID: > > Content-Type: text/plain; charset=utf-8 > > > > One good thing is that Oracle has not yet filed a JSR for Java EE > > concurrency utilities targeting Java EE 8. That means any interested > > parties could do so and perhaps that could be better for the community in > > the end anyway. > > > > Certainly starting prototyping some of these things will make it clearer > > where they belong or could be contributed to in the end. > > > > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau > > > wrote: > > > > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > > >> Responses in-line: > > >> > > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> > > wrote: > > >>> > > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > > >>>> In terms of CDI and EJB alignment, I think these would have the most > > >>>> value to the community going forward: > > >>>> > > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has > > >>>> similarly nice syntax to handle eager loading). > > >>> > > >>> @Startup is there with @Initialized(ApplicationScoped) event > > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy > > >>> and full of proxies so not sure it would bring much to the game > > >>> without bringing really much more like @Schedule etc... > > >> > > >> Yes, I know but eager loading is a common enough case to warrant > better > > syntax/usability. > > > > > > fair enough > > > > > >>> > > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for > > CDI. > > >>>> These are very useful bits of functionality that should be available > > to > > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be > > >>>> extremely useful. EJB @Schedule is similarly useful but likely not > > right > > >>>> for CDI proper as it does not have that much to do with component > > >>>> life-cycle/bean access management. The others I think are quite > > natural > > >>>> fits for the core of a DI framework (in fact it may be awkward to > have > > >>>> them elsewhere). > > >>> > > >>> > > >>> Think concurrency utilities can have a CDI integration rather than > > >>> putting everything in CDI. It is globally all interceptors - at least > > >>> in term of design - so would make sense to have them outside IMO - > but > > >>> a big +1 to get them cleanly added on top of CDI. > > >> > > >> Keep in mind, Java EE concurrency utilities is also minimally > resourced > > and that's unlikely to change in the future. I would say if we think > these > > features would help community/CDI adoption, it's likely wisest to find a > > way to do it in CDI proper. As I alluded to, these are also a bit easier > to > > implement at the core DI container level than via interceptors. Things > like > > @Transcational, @Schedule are easier as interceptors since they don't > have > > as much to do with the internals of the component life-cycle and instance > > access control. > > > > > > well yes and not, it would be awesome to control where the concurrency > > > is exactly in the stack and it would mean being able to change > > > @Priority for instance. > > > > > > Overall point being that if we put features only where resources are > > > instead of trying to put them where they fit and try to help these > > > specs CDI will likely handle javascript integration soon ;). > > > > > > Concurrency and throttling have a potential spec which would be > > > welcomed in these very distributed days, we just need to find people > > > motivated enough to make it moving forward IMO. > > > > > >>> > > >>>> > > >>>> As to doing more work in EJB, honestly it's likely best to leave EJB > > be > > >>>> at this stage. If there is a compelling reason that helps the > platform > > >>>> and CDI generally we can see if it can be done. By default, EJB is > > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to > > >>>> change at this stage. In the community I have mostly seen requests > for > > >>>> moving functionality out of EJB into CDI rather than the other way > > around... > > >>>> > > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > > >>>>> Hi! > > >>>>> > > >>>>> We already do a decent amount of ?side-by-side? handling in EJB and > > CDI. But there are still many aready where we could really move together > > much closer. > > >>>>> > > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted > by > > the EJB container. But what happens with ProcessAnnotatedType#veto(). > This > > one is not defined that clearly I fear. > > >>>>> > > >>>>> What if we (of course together with the EJB spec group) define that > > the EJB container must create the EJBs according to the effective > > AnnotatedType coming out after ProcessAnnotatedType? This would define > that > > EJBs can also get modified via CDI Extensions. Some container do that > > already. > > >>>>> The benefit of explicitly writing this down would obviously be that > > we would allow EJB to fully utilize the power of CDI Extensions in a > > portable way. > > >>>>> > > >>>>> Any objections, any ideas, any howtos? > > >>>>> > > >>>>> Let the ideas roll ;) > > >>>>> > > >>>>> LieGrue, > > >>>>> strub > > >>>>> _______________________________________________ > > >>>>> cdi-dev mailing list > > >>>>> cdi-dev at lists.jboss.org > > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >>>>> > > >>>>> Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > >>>> > > >>>> _______________________________________________ > > >>>> cdi-dev mailing list > > >>>> cdi-dev at lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >>>> > > >>>> Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 17 Nov 2015 14:44:35 +0100 > > From: Antonio Goncalves > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > To: Reza Rahman > > Cc: "cdi-dev at lists.jboss.org" > > Message-ID: > > < > > CA+ZZq98nGkMYUj5uEt7UuGHFcttdoi7zTiH_mWK5n_9zy2EaNQ at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > HI all, > > > > This discussion comes back on and off. > > > > At the last F2F meeting, we talked about having @Startup and @Shutdown in > > JSR 250. Talking to Bill and Linda, they don't seem reluctant to update > the > > spec. No need to have @DependsOn as we will use @Priority with @Startup. > > > > @Schedule should go to Java EE Concurrency (implemented as a CDI > > interceptor) but not in CDI as this would be just moving more stuff > inside > > CDI (which will end up as big as EJBs). Same for @Asynchronous. > > > > So what could be doable in CDI 2.1 is having @Startup and @Shutdown > > implemented... but the annotations would be in JSR 250. > > > > Antonio > > > > > > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman > > wrote: > > > > > One good thing is that Oracle has not yet filed a JSR for Java EE > > > concurrency utilities targeting Java EE 8. That means any interested > > > parties could do so and perhaps that could be better for the community > in > > > the end anyway. > > > > > > Certainly starting prototyping some of these things will make it > clearer > > > where they belong or could be contributed to in the end. > > > > > > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau < > rmannibucau at gmail.com > > > > > > wrote: > > > > > > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > > > >> Responses in-line: > > > >> > > > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < > > rmannibucau at gmail.com> > > > wrote: > > > >>> > > > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > > > >>>> In terms of CDI and EJB alignment, I think these would have the > most > > > >>>> value to the community going forward: > > > >>>> > > > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core > has > > > >>>> similarly nice syntax to handle eager loading). > > > >>> > > > >>> @Startup is there with @Initialized(ApplicationScoped) event > > > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy > > > >>> and full of proxies so not sure it would bring much to the game > > > >>> without bringing really much more like @Schedule etc... > > > >> > > > >> Yes, I know but eager loading is a common enough case to warrant > > better > > > syntax/usability. > > > > > > > > fair enough > > > > > > > >>> > > > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout > for > > > CDI. > > > >>>> These are very useful bits of functionality that should be > available > > > to > > > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also > be > > > >>>> extremely useful. EJB @Schedule is similarly useful but likely not > > > right > > > >>>> for CDI proper as it does not have that much to do with component > > > >>>> life-cycle/bean access management. The others I think are quite > > > natural > > > >>>> fits for the core of a DI framework (in fact it may be awkward to > > have > > > >>>> them elsewhere). > > > >>> > > > >>> > > > >>> Think concurrency utilities can have a CDI integration rather than > > > >>> putting everything in CDI. It is globally all interceptors - at > least > > > >>> in term of design - so would make sense to have them outside IMO - > > but > > > >>> a big +1 to get them cleanly added on top of CDI. > > > >> > > > >> Keep in mind, Java EE concurrency utilities is also minimally > > resourced > > > and that's unlikely to change in the future. I would say if we think > > these > > > features would help community/CDI adoption, it's likely wisest to find > a > > > way to do it in CDI proper. As I alluded to, these are also a bit > easier > > to > > > implement at the core DI container level than via interceptors. Things > > like > > > @Transcational, @Schedule are easier as interceptors since they don't > > have > > > as much to do with the internals of the component life-cycle and > instance > > > access control. > > > > > > > > well yes and not, it would be awesome to control where the > concurrency > > > > is exactly in the stack and it would mean being able to change > > > > @Priority for instance. > > > > > > > > Overall point being that if we put features only where resources are > > > > instead of trying to put them where they fit and try to help these > > > > specs CDI will likely handle javascript integration soon ;). > > > > > > > > Concurrency and throttling have a potential spec which would be > > > > welcomed in these very distributed days, we just need to find people > > > > motivated enough to make it moving forward IMO. > > > > > > > >>> > > > >>>> > > > >>>> As to doing more work in EJB, honestly it's likely best to leave > EJB > > > be > > > >>>> at this stage. If there is a compelling reason that helps the > > platform > > > >>>> and CDI generally we can see if it can be done. By default, EJB is > > > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to > > > >>>> change at this stage. In the community I have mostly seen requests > > for > > > >>>> moving functionality out of EJB into CDI rather than the other way > > > around... > > > >>>> > > > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > > > >>>>> Hi! > > > >>>>> > > > >>>>> We already do a decent amount of ?side-by-side? handling in EJB > and > > > CDI. But there are still many aready where we could really move > together > > > much closer. > > > >>>>> > > > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted > > by > > > the EJB container. But what happens with ProcessAnnotatedType#veto(). > > This > > > one is not defined that clearly I fear. > > > >>>>> > > > >>>>> What if we (of course together with the EJB spec group) define > that > > > the EJB container must create the EJBs according to the effective > > > AnnotatedType coming out after ProcessAnnotatedType? This would define > > that > > > EJBs can also get modified via CDI Extensions. Some container do that > > > already. > > > >>>>> The benefit of explicitly writing this down would obviously be > that > > > we would allow EJB to fully utilize the power of CDI Extensions in a > > > portable way. > > > >>>>> > > > >>>>> Any objections, any ideas, any howtos? > > > >>>>> > > > >>>>> Let the ideas roll ;) > > > >>>>> > > > >>>>> LieGrue, > > > >>>>> strub > > > >>>>> _______________________________________________ > > > >>>>> cdi-dev mailing list > > > >>>>> cdi-dev at lists.jboss.org > > > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > > >>>>> > > > >>>>> Note that for all code provided on this list, the provider > licenses > > > the code under the Apache License, Version 2 ( > > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > > provided on this list, the provider waives all patent and other > > > intellectual property rights inherent in such information. > > > >>>> > > > >>>> _______________________________________________ > > > >>>> cdi-dev mailing list > > > >>>> cdi-dev at lists.jboss.org > > > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > > >>>> > > > >>>> Note that for all code provided on this list, the provider > licenses > > > the code under the Apache License, Version 2 ( > > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > > provided on this list, the provider waives all patent and other > > > intellectual property rights inherent in such information. > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses the > > > code under the Apache License, Version 2 ( > > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > > provided on this list, the provider waives all patent and other > > > intellectual property rights inherent in such information. > > > > > > > > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site | Twitter > > | LinkedIn < > > http://www.linkedin.com/in/agoncal> | > > Pluralsight > > | > > Paris > > JUG | Devoxx France > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/attachment-0001.html > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 17 Nov 2015 15:03:32 +0100 > > From: arjan tijms > > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > > To: Antonio Goncalves > > Cc: "cdi-dev at lists.jboss.org" > > Message-ID: > > > AhAhn2W-yvJgGHQdv7PNS2jjGbJouxNirYOKyekuy9s3mQ at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Hi, > > > > On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < > > antonio.goncalves at gmail.com> wrote: > > > > > @Schedule should go to Java EE Concurrency (implemented as a CDI > > > interceptor) but not in CDI as this would be just moving more stuff > > inside > > > CDI (which will end up as big as EJBs). Same for @Asynchronous. > > > > > > > 100% agree with this. It's almost better not to do things if absolutely > > needed, then burden CDI with some concerns it perhaps should not be > > concerned with. It's already problematic that CDI crossed this bridge > once > > with providing a Bean for Servlet and other artifacts it doesn't own. > > > > As for @Asynchronous, a basic prototype implementation has already been > > created by several parties. I did one here: > > http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld > > team > > did one here: > > > > > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java > > > > Also interesting would be to go a little beyond what the EJB vesion > offers > > and add support for a completable feature and optionally named thread > > pools. > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > > > So what could be doable in CDI 2.1 is having @Startup and @Shutdown > > > implemented... but the annotations would be in JSR 250. > > > > > > Antonio > > > > > > > > > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman > > > wrote: > > > > > >> One good thing is that Oracle has not yet filed a JSR for Java EE > > >> concurrency utilities targeting Java EE 8. That means any interested > > >> parties could do so and perhaps that could be better for the community > > in > > >> the end anyway. > > >> > > >> Certainly starting prototyping some of these things will make it > clearer > > >> where they belong or could be contributed to in the end. > > >> > > >> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau < > > rmannibucau at gmail.com> > > >> wrote: > > >> > > > >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > > >> >> Responses in-line: > > >> >> > > >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < > > >> rmannibucau at gmail.com> wrote: > > >> >>> > > >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > > >> >>>> In terms of CDI and EJB alignment, I think these would have the > > most > > >> >>>> value to the community going forward: > > >> >>>> > > >> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core > > has > > >> >>>> similarly nice syntax to handle eager loading). > > >> >>> > > >> >>> @Startup is there with @Initialized(ApplicationScoped) event > > >> >>> @DependsOn is less important than for EJB IMO cause all CDI is > lazy > > >> >>> and full of proxies so not sure it would bring much to the game > > >> >>> without bringing really much more like @Schedule etc... > > >> >> > > >> >> Yes, I know but eager loading is a common enough case to warrant > > >> better syntax/usability. > > >> > > > >> > fair enough > > >> > > > >> >>> > > >> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout > for > > >> CDI. > > >> >>>> These are very useful bits of functionality that should be > > available > > >> to > > >> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also > > be > > >> >>>> extremely useful. EJB @Schedule is similarly useful but likely > not > > >> right > > >> >>>> for CDI proper as it does not have that much to do with component > > >> >>>> life-cycle/bean access management. The others I think are quite > > >> natural > > >> >>>> fits for the core of a DI framework (in fact it may be awkward to > > >> have > > >> >>>> them elsewhere). > > >> >>> > > >> >>> > > >> >>> Think concurrency utilities can have a CDI integration rather than > > >> >>> putting everything in CDI. It is globally all interceptors - at > > least > > >> >>> in term of design - so would make sense to have them outside IMO - > > but > > >> >>> a big +1 to get them cleanly added on top of CDI. > > >> >> > > >> >> Keep in mind, Java EE concurrency utilities is also minimally > > >> resourced and that's unlikely to change in the future. I would say if > we > > >> think these features would help community/CDI adoption, it's likely > > wisest > > >> to find a way to do it in CDI proper. As I alluded to, these are also > a > > bit > > >> easier to implement at the core DI container level than via > > interceptors. > > >> Things like @Transcational, @Schedule are easier as interceptors since > > they > > >> don't have as much to do with the internals of the component > life-cycle > > and > > >> instance access control. > > >> > > > >> > well yes and not, it would be awesome to control where the > concurrency > > >> > is exactly in the stack and it would mean being able to change > > >> > @Priority for instance. > > >> > > > >> > Overall point being that if we put features only where resources are > > >> > instead of trying to put them where they fit and try to help these > > >> > specs CDI will likely handle javascript integration soon ;). > > >> > > > >> > Concurrency and throttling have a potential spec which would be > > >> > welcomed in these very distributed days, we just need to find people > > >> > motivated enough to make it moving forward IMO. > > >> > > > >> >>> > > >> >>>> > > >> >>>> As to doing more work in EJB, honestly it's likely best to leave > > EJB > > >> be > > >> >>>> at this stage. If there is a compelling reason that helps the > > >> platform > > >> >>>> and CDI generally we can see if it can be done. By default, EJB > is > > >> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard > to > > >> >>>> change at this stage. In the community I have mostly seen > requests > > >> for > > >> >>>> moving functionality out of EJB into CDI rather than the other > way > > >> around... > > >> >>>> > > >> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > > >> >>>>> Hi! > > >> >>>>> > > >> >>>>> We already do a decent amount of ?side-by-side? handling in EJB > > and > > >> CDI. But there are still many aready where we could really move > together > > >> much closer. > > >> >>>>> > > >> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get > accounted > > >> by the EJB container. But what happens with > ProcessAnnotatedType#veto(). > > >> This one is not defined that clearly I fear. > > >> >>>>> > > >> >>>>> What if we (of course together with the EJB spec group) define > > that > > >> the EJB container must create the EJBs according to the effective > > >> AnnotatedType coming out after ProcessAnnotatedType? This would define > > that > > >> EJBs can also get modified via CDI Extensions. Some container do that > > >> already. > > >> >>>>> The benefit of explicitly writing this down would obviously be > > that > > >> we would allow EJB to fully utilize the power of CDI Extensions in a > > >> portable way. > > >> >>>>> > > >> >>>>> Any objections, any ideas, any howtos? > > >> >>>>> > > >> >>>>> Let the ideas roll ;) > > >> >>>>> > > >> >>>>> LieGrue, > > >> >>>>> strub > > >> >>>>> _______________________________________________ > > >> >>>>> cdi-dev mailing list > > >> >>>>> cdi-dev at lists.jboss.org > > >> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> >>>>> > > >> >>>>> Note that for all code provided on this list, the provider > > licenses > > >> the code under the Apache License, Version 2 ( > > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > >> provided on this list, the provider waives all patent and other > > >> intellectual property rights inherent in such information. > > >> >>>> > > >> >>>> _______________________________________________ > > >> >>>> cdi-dev mailing list > > >> >>>> cdi-dev at lists.jboss.org > > >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> >>>> > > >> >>>> Note that for all code provided on this list, the provider > licenses > > >> the code under the Apache License, Version 2 ( > > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > >> provided on this list, the provider waives all patent and other > > >> intellectual property rights inherent in such information. > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> > > >> Note that for all code provided on this list, the provider licenses > the > > >> code under the Apache License, Version 2 ( > > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > >> provided on this list, the provider waives all patent and other > > >> intellectual property rights inherent in such information. > > >> > > > > > > > > > > > > -- > > > Antonio Goncalves > > > Software architect, Java Champion and Pluralsight author > > > > > > Web site | Twitter > > > | LinkedIn > > > | Pluralsight > > > | > > Paris > > > JUG | Devoxx France > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider licenses the > > > code under the Apache License, Version 2 ( > > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > > provided on this list, the provider waives all patent and other > > > intellectual property rights inherent in such information. > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/c074f5ae/attachment.html > > > > ------------------------------ > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 ( > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > > > End of cdi-dev Digest, Vol 60, Issue 13 > > *************************************** > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/b1fb79c2/attachment.html > > ------------------------------ > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > End of cdi-dev Digest, Vol 60, Issue 14 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/5c37daa9/attachment-0001.html From reza.rahman at oracle.com Tue Nov 17 09:28:13 2015 From: reza.rahman at oracle.com (Reza Rahman) Date: Tue, 17 Nov 2015 09:28:13 -0500 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: Message-ID: <549CEEB3-EC7D-44F2-8FD0-F6D8B218D814@oracle.com> I personally think it is always great for parties other than Oracle to lead Java EE specifications. That is a large portion of what the openness of the JCP is supposed to be about after all. > On Nov 17, 2015, at 9:17 AM, Werner Keil wrote: > > Reza/all, > > Do you suggest, others could/should take over as Spec Lead of a new Java EE Concurrency JSR or just gather ideas and do brainstorming, similar to e.g. what happens in JSR 375? > > Werner > > > >> On Tue, Nov 17, 2015 at 1:37 PM, wrote: >> Send cdi-dev mailing list submissions to >> cdi-dev at lists.jboss.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> or, via email, send a message with subject or body 'help' to >> cdi-dev-request at lists.jboss.org >> >> You can reach the person managing the list at >> cdi-dev-owner at lists.jboss.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of cdi-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) >> 2. Re: [PROPOSAL] further align CDI and EJB (Antonio Goncalves) >> 3. Re: [PROPOSAL] further align CDI and EJB (arjan tijms) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 16 Nov 2015 18:55:04 -0500 >> From: Reza Rahman >> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> To: "cdi-dev at lists.jboss.org" >> Message-ID: >> Content-Type: text/plain; charset=utf-8 >> >> One good thing is that Oracle has not yet filed a JSR for Java EE concurrency utilities targeting Java EE 8. That means any interested parties could do so and perhaps that could be better for the community in the end anyway. >> >> Certainly starting prototyping some of these things will make it clearer where they belong or could be contributed to in the end. >> >> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau wrote: >> > >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> >> Responses in-line: >> >> >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau wrote: >> >>> >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> >>>> In terms of CDI and EJB alignment, I think these would have the most >> >>>> value to the community going forward: >> >>>> >> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >> >>>> similarly nice syntax to handle eager loading). >> >>> >> >>> @Startup is there with @Initialized(ApplicationScoped) event >> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> >>> and full of proxies so not sure it would bring much to the game >> >>> without bringing really much more like @Schedule etc... >> >> >> >> Yes, I know but eager loading is a common enough case to warrant better syntax/usability. >> > >> > fair enough >> > >> >>> >> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for CDI. >> >>>> These are very useful bits of functionality that should be available to >> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >> >>>> extremely useful. EJB @Schedule is similarly useful but likely not right >> >>>> for CDI proper as it does not have that much to do with component >> >>>> life-cycle/bean access management. The others I think are quite natural >> >>>> fits for the core of a DI framework (in fact it may be awkward to have >> >>>> them elsewhere). >> >>> >> >>> >> >>> Think concurrency utilities can have a CDI integration rather than >> >>> putting everything in CDI. It is globally all interceptors - at least >> >>> in term of design - so would make sense to have them outside IMO - but >> >>> a big +1 to get them cleanly added on top of CDI. >> >> >> >> Keep in mind, Java EE concurrency utilities is also minimally resourced and that's unlikely to change in the future. I would say if we think these features would help community/CDI adoption, it's likely wisest to find a way to do it in CDI proper. As I alluded to, these are also a bit easier to implement at the core DI container level than via interceptors. Things like @Transcational, @Schedule are easier as interceptors since they don't have as much to do with the internals of the component life-cycle and instance access control. >> > >> > well yes and not, it would be awesome to control where the concurrency >> > is exactly in the stack and it would mean being able to change >> > @Priority for instance. >> > >> > Overall point being that if we put features only where resources are >> > instead of trying to put them where they fit and try to help these >> > specs CDI will likely handle javascript integration soon ;). >> > >> > Concurrency and throttling have a potential spec which would be >> > welcomed in these very distributed days, we just need to find people >> > motivated enough to make it moving forward IMO. >> > >> >>> >> >>>> >> >>>> As to doing more work in EJB, honestly it's likely best to leave EJB be >> >>>> at this stage. If there is a compelling reason that helps the platform >> >>>> and CDI generally we can see if it can be done. By default, EJB is >> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >> >>>> change at this stage. In the community I have mostly seen requests for >> >>>> moving functionality out of EJB into CDI rather than the other way around... >> >>>> >> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> >>>>> Hi! >> >>>>> >> >>>>> We already do a decent amount of ?side-by-side? handling in EJB and CDI. But there are still many aready where we could really move together much closer. >> >>>>> >> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by the EJB container. But what happens with ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >> >>>>> >> >>>>> What if we (of course together with the EJB spec group) define that the EJB container must create the EJBs according to the effective AnnotatedType coming out after ProcessAnnotatedType? This would define that EJBs can also get modified via CDI Extensions. Some container do that already. >> >>>>> The benefit of explicitly writing this down would obviously be that we would allow EJB to fully utilize the power of CDI Extensions in a portable way. >> >>>>> >> >>>>> Any objections, any ideas, any howtos? >> >>>>> >> >>>>> Let the ideas roll ;) >> >>>>> >> >>>>> LieGrue, >> >>>>> strub >> >>>>> _______________________________________________ >> >>>>> cdi-dev mailing list >> >>>>> cdi-dev at lists.jboss.org >> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>> >> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >>>> >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 17 Nov 2015 14:44:35 +0100 >> From: Antonio Goncalves >> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> To: Reza Rahman >> Cc: "cdi-dev at lists.jboss.org" >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> HI all, >> >> This discussion comes back on and off. >> >> At the last F2F meeting, we talked about having @Startup and @Shutdown in >> JSR 250. Talking to Bill and Linda, they don't seem reluctant to update the >> spec. No need to have @DependsOn as we will use @Priority with @Startup. >> >> @Schedule should go to Java EE Concurrency (implemented as a CDI >> interceptor) but not in CDI as this would be just moving more stuff inside >> CDI (which will end up as big as EJBs). Same for @Asynchronous. >> >> So what could be doable in CDI 2.1 is having @Startup and @Shutdown >> implemented... but the annotations would be in JSR 250. >> >> Antonio >> >> >> On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman >> wrote: >> >> > One good thing is that Oracle has not yet filed a JSR for Java EE >> > concurrency utilities targeting Java EE 8. That means any interested >> > parties could do so and perhaps that could be better for the community in >> > the end anyway. >> > >> > Certainly starting prototyping some of these things will make it clearer >> > where they belong or could be contributed to in the end. >> > >> > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau >> > wrote: >> > > >> > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> > >> Responses in-line: >> > >> >> > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau >> > wrote: >> > >>> >> > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> > >>>> In terms of CDI and EJB alignment, I think these would have the most >> > >>>> value to the community going forward: >> > >>>> >> > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >> > >>>> similarly nice syntax to handle eager loading). >> > >>> >> > >>> @Startup is there with @Initialized(ApplicationScoped) event >> > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> > >>> and full of proxies so not sure it would bring much to the game >> > >>> without bringing really much more like @Schedule etc... >> > >> >> > >> Yes, I know but eager loading is a common enough case to warrant better >> > syntax/usability. >> > > >> > > fair enough >> > > >> > >>> >> > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for >> > CDI. >> > >>>> These are very useful bits of functionality that should be available >> > to >> > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >> > >>>> extremely useful. EJB @Schedule is similarly useful but likely not >> > right >> > >>>> for CDI proper as it does not have that much to do with component >> > >>>> life-cycle/bean access management. The others I think are quite >> > natural >> > >>>> fits for the core of a DI framework (in fact it may be awkward to have >> > >>>> them elsewhere). >> > >>> >> > >>> >> > >>> Think concurrency utilities can have a CDI integration rather than >> > >>> putting everything in CDI. It is globally all interceptors - at least >> > >>> in term of design - so would make sense to have them outside IMO - but >> > >>> a big +1 to get them cleanly added on top of CDI. >> > >> >> > >> Keep in mind, Java EE concurrency utilities is also minimally resourced >> > and that's unlikely to change in the future. I would say if we think these >> > features would help community/CDI adoption, it's likely wisest to find a >> > way to do it in CDI proper. As I alluded to, these are also a bit easier to >> > implement at the core DI container level than via interceptors. Things like >> > @Transcational, @Schedule are easier as interceptors since they don't have >> > as much to do with the internals of the component life-cycle and instance >> > access control. >> > > >> > > well yes and not, it would be awesome to control where the concurrency >> > > is exactly in the stack and it would mean being able to change >> > > @Priority for instance. >> > > >> > > Overall point being that if we put features only where resources are >> > > instead of trying to put them where they fit and try to help these >> > > specs CDI will likely handle javascript integration soon ;). >> > > >> > > Concurrency and throttling have a potential spec which would be >> > > welcomed in these very distributed days, we just need to find people >> > > motivated enough to make it moving forward IMO. >> > > >> > >>> >> > >>>> >> > >>>> As to doing more work in EJB, honestly it's likely best to leave EJB >> > be >> > >>>> at this stage. If there is a compelling reason that helps the platform >> > >>>> and CDI generally we can see if it can be done. By default, EJB is >> > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >> > >>>> change at this stage. In the community I have mostly seen requests for >> > >>>> moving functionality out of EJB into CDI rather than the other way >> > around... >> > >>>> >> > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> > >>>>> Hi! >> > >>>>> >> > >>>>> We already do a decent amount of ?side-by-side? handling in EJB and >> > CDI. But there are still many aready where we could really move together >> > much closer. >> > >>>>> >> > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by >> > the EJB container. But what happens with ProcessAnnotatedType#veto(). This >> > one is not defined that clearly I fear. >> > >>>>> >> > >>>>> What if we (of course together with the EJB spec group) define that >> > the EJB container must create the EJBs according to the effective >> > AnnotatedType coming out after ProcessAnnotatedType? This would define that >> > EJBs can also get modified via CDI Extensions. Some container do that >> > already. >> > >>>>> The benefit of explicitly writing this down would obviously be that >> > we would allow EJB to fully utilize the power of CDI Extensions in a >> > portable way. >> > >>>>> >> > >>>>> Any objections, any ideas, any howtos? >> > >>>>> >> > >>>>> Let the ideas roll ;) >> > >>>>> >> > >>>>> LieGrue, >> > >>>>> strub >> > >>>>> _______________________________________________ >> > >>>>> cdi-dev mailing list >> > >>>>> cdi-dev at lists.jboss.org >> > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >>>>> >> > >>>>> Note that for all code provided on this list, the provider licenses >> > the code under the Apache License, Version 2 ( >> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > provided on this list, the provider waives all patent and other >> > intellectual property rights inherent in such information. >> > >>>> >> > >>>> _______________________________________________ >> > >>>> cdi-dev mailing list >> > >>>> cdi-dev at lists.jboss.org >> > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >>>> >> > >>>> Note that for all code provided on this list, the provider licenses >> > the code under the Apache License, Version 2 ( >> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > provided on this list, the provider waives all patent and other >> > intellectual property rights inherent in such information. >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> > code under the Apache License, Version 2 ( >> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > provided on this list, the provider waives all patent and other >> > intellectual property rights inherent in such information. >> > >> >> >> >> -- >> Antonio Goncalves >> Software architect, Java Champion and Pluralsight author >> >> Web site | Twitter >> | LinkedIn | >> Pluralsight >> | Paris >> JUG | Devoxx France >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/attachment-0001.html >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 17 Nov 2015 15:03:32 +0100 >> From: arjan tijms >> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> To: Antonio Goncalves >> Cc: "cdi-dev at lists.jboss.org" >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, >> >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < >> antonio.goncalves at gmail.com> wrote: >> >> > @Schedule should go to Java EE Concurrency (implemented as a CDI >> > interceptor) but not in CDI as this would be just moving more stuff inside >> > CDI (which will end up as big as EJBs). Same for @Asynchronous. >> > >> >> 100% agree with this. It's almost better not to do things if absolutely >> needed, then burden CDI with some concerns it perhaps should not be >> concerned with. It's already problematic that CDI crossed this bridge once >> with providing a Bean for Servlet and other artifacts it doesn't own. >> >> As for @Asynchronous, a basic prototype implementation has already been >> created by several parties. I did one here: >> http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld team >> did one here: >> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java >> >> Also interesting would be to go a little beyond what the EJB vesion offers >> and add support for a completable feature and optionally named thread pools. >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> > >> > So what could be doable in CDI 2.1 is having @Startup and @Shutdown >> > implemented... but the annotations would be in JSR 250. >> > >> > Antonio >> > >> > >> > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman >> > wrote: >> > >> >> One good thing is that Oracle has not yet filed a JSR for Java EE >> >> concurrency utilities targeting Java EE 8. That means any interested >> >> parties could do so and perhaps that could be better for the community in >> >> the end anyway. >> >> >> >> Certainly starting prototyping some of these things will make it clearer >> >> where they belong or could be contributed to in the end. >> >> >> >> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau >> >> wrote: >> >> > >> >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> >> >> Responses in-line: >> >> >> >> >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < >> >> rmannibucau at gmail.com> wrote: >> >> >>> >> >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> >> >>>> In terms of CDI and EJB alignment, I think these would have the most >> >> >>>> value to the community going forward: >> >> >>>> >> >> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >> >> >>>> similarly nice syntax to handle eager loading). >> >> >>> >> >> >>> @Startup is there with @Initialized(ApplicationScoped) event >> >> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> >> >>> and full of proxies so not sure it would bring much to the game >> >> >>> without bringing really much more like @Schedule etc... >> >> >> >> >> >> Yes, I know but eager loading is a common enough case to warrant >> >> better syntax/usability. >> >> > >> >> > fair enough >> >> > >> >> >>> >> >> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for >> >> CDI. >> >> >>>> These are very useful bits of functionality that should be available >> >> to >> >> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >> >> >>>> extremely useful. EJB @Schedule is similarly useful but likely not >> >> right >> >> >>>> for CDI proper as it does not have that much to do with component >> >> >>>> life-cycle/bean access management. The others I think are quite >> >> natural >> >> >>>> fits for the core of a DI framework (in fact it may be awkward to >> >> have >> >> >>>> them elsewhere). >> >> >>> >> >> >>> >> >> >>> Think concurrency utilities can have a CDI integration rather than >> >> >>> putting everything in CDI. It is globally all interceptors - at least >> >> >>> in term of design - so would make sense to have them outside IMO - but >> >> >>> a big +1 to get them cleanly added on top of CDI. >> >> >> >> >> >> Keep in mind, Java EE concurrency utilities is also minimally >> >> resourced and that's unlikely to change in the future. I would say if we >> >> think these features would help community/CDI adoption, it's likely wisest >> >> to find a way to do it in CDI proper. As I alluded to, these are also a bit >> >> easier to implement at the core DI container level than via interceptors. >> >> Things like @Transcational, @Schedule are easier as interceptors since they >> >> don't have as much to do with the internals of the component life-cycle and >> >> instance access control. >> >> > >> >> > well yes and not, it would be awesome to control where the concurrency >> >> > is exactly in the stack and it would mean being able to change >> >> > @Priority for instance. >> >> > >> >> > Overall point being that if we put features only where resources are >> >> > instead of trying to put them where they fit and try to help these >> >> > specs CDI will likely handle javascript integration soon ;). >> >> > >> >> > Concurrency and throttling have a potential spec which would be >> >> > welcomed in these very distributed days, we just need to find people >> >> > motivated enough to make it moving forward IMO. >> >> > >> >> >>> >> >> >>>> >> >> >>>> As to doing more work in EJB, honestly it's likely best to leave EJB >> >> be >> >> >>>> at this stage. If there is a compelling reason that helps the >> >> platform >> >> >>>> and CDI generally we can see if it can be done. By default, EJB is >> >> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >> >> >>>> change at this stage. In the community I have mostly seen requests >> >> for >> >> >>>> moving functionality out of EJB into CDI rather than the other way >> >> around... >> >> >>>> >> >> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> >> >>>>> Hi! >> >> >>>>> >> >> >>>>> We already do a decent amount of ?side-by-side? handling in EJB and >> >> CDI. But there are still many aready where we could really move together >> >> much closer. >> >> >>>>> >> >> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted >> >> by the EJB container. But what happens with ProcessAnnotatedType#veto(). >> >> This one is not defined that clearly I fear. >> >> >>>>> >> >> >>>>> What if we (of course together with the EJB spec group) define that >> >> the EJB container must create the EJBs according to the effective >> >> AnnotatedType coming out after ProcessAnnotatedType? This would define that >> >> EJBs can also get modified via CDI Extensions. Some container do that >> >> already. >> >> >>>>> The benefit of explicitly writing this down would obviously be that >> >> we would allow EJB to fully utilize the power of CDI Extensions in a >> >> portable way. >> >> >>>>> >> >> >>>>> Any objections, any ideas, any howtos? >> >> >>>>> >> >> >>>>> Let the ideas roll ;) >> >> >>>>> >> >> >>>>> LieGrue, >> >> >>>>> strub >> >> >>>>> _______________________________________________ >> >> >>>>> cdi-dev mailing list >> >> >>>>> cdi-dev at lists.jboss.org >> >> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >>>>> >> >> >>>>> Note that for all code provided on this list, the provider licenses >> >> the code under the Apache License, Version 2 ( >> >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> >> provided on this list, the provider waives all patent and other >> >> intellectual property rights inherent in such information. >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> cdi-dev mailing list >> >> >>>> cdi-dev at lists.jboss.org >> >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >>>> >> >> >>>> Note that for all code provided on this list, the provider licenses >> >> the code under the Apache License, Version 2 ( >> >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> >> provided on this list, the provider waives all patent and other >> >> intellectual property rights inherent in such information. >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses the >> >> code under the Apache License, Version 2 ( >> >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> >> provided on this list, the provider waives all patent and other >> >> intellectual property rights inherent in such information. >> >> >> > >> > >> > >> > -- >> > Antonio Goncalves >> > Software architect, Java Champion and Pluralsight author >> > >> > Web site | Twitter >> > | LinkedIn >> > | Pluralsight >> > | Paris >> > JUG | Devoxx France >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> > code under the Apache License, Version 2 ( >> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > provided on this list, the provider waives all patent and other >> > intellectual property rights inherent in such information. >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/c074f5ae/attachment.html >> >> ------------------------------ >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> End of cdi-dev Digest, Vol 60, Issue 13 >> *************************************** > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/14e55fe0/attachment-0001.html From reza.rahman at oracle.com Tue Nov 17 09:35:26 2015 From: reza.rahman at oracle.com (Reza Rahman) Date: Tue, 17 Nov 2015 09:35:26 -0500 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: Message-ID: <8F72B305-5264-4C52-921C-84A4C165A2AA@oracle.com> To be honest I couldn't tell you what exactly the officially sanctioned Oracle position is with regards to non-Oracle led specifications. What I am sure about personally is that greater contribution from many sources into Java EE specifications is the right thing to do now and has been all along. I don't think you need to look beyond the role of CDI in Java EE 6 success to see evidence of that. > On Nov 17, 2015, at 9:25 AM, Werner Keil wrote: > > Looking at the EG of JSR 236 however, other than 2 JCP Award winners in the member category (Doug Lea and Adam Bien, the latter did however admit when he picked his award, he wasn't sure who nominated him, and that at least when it comes to active involvement in JSRs he was far from active in any of them;-) there are pretty much the "Big 3" IBM, Oracle Red Hat (in alphabetical order) only in that EG. > > So should Oracle prefer someone took the Spec Lead role for Java EE Concurrency.next, who other than those Big 3 would be a suitable Spec Lead or Co Spec Lead? > > I know what it means, since I am also Spec Lead of an active JSR, but that is more than enough until that's gone final. Sure, there are other Individual or corporate members in this and other EE EGs who might be a good fit for that aside from say the obvious Doug Lea;-) > > Werner > >> On Tue, Nov 17, 2015 at 1:51 PM, wrote: >> Send cdi-dev mailing list submissions to >> cdi-dev at lists.jboss.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> or, via email, send a message with subject or body 'help' to >> cdi-dev-request at lists.jboss.org >> >> You can reach the person managing the list at >> cdi-dev-owner at lists.jboss.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of cdi-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: [PROPOSAL] further align CDI and EJB (Werner Keil) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 17 Nov 2015 15:17:58 +0100 >> From: Werner Keil >> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> To: cdi-dev >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Reza/all, >> >> Do you suggest, others could/should take over as Spec Lead of a new Java EE >> Concurrency JSR or just gather ideas and do brainstorming, similar to e.g. >> what happens in JSR 375? >> >> Werner >> >> >> >> On Tue, Nov 17, 2015 at 1:37 PM, wrote: >> >> > Send cdi-dev mailing list submissions to >> > cdi-dev at lists.jboss.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > or, via email, send a message with subject or body 'help' to >> > cdi-dev-request at lists.jboss.org >> > >> > You can reach the person managing the list at >> > cdi-dev-owner at lists.jboss.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of cdi-dev digest..." >> > >> > >> > Today's Topics: >> > >> > 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) >> > 2. Re: [PROPOSAL] further align CDI and EJB (Antonio Goncalves) >> > 3. Re: [PROPOSAL] further align CDI and EJB (arjan tijms) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Mon, 16 Nov 2015 18:55:04 -0500 >> > From: Reza Rahman >> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> > To: "cdi-dev at lists.jboss.org" >> > Message-ID: >> > Content-Type: text/plain; charset=utf-8 >> > >> > One good thing is that Oracle has not yet filed a JSR for Java EE >> > concurrency utilities targeting Java EE 8. That means any interested >> > parties could do so and perhaps that could be better for the community in >> > the end anyway. >> > >> > Certainly starting prototyping some of these things will make it clearer >> > where they belong or could be contributed to in the end. >> > >> > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau >> > wrote: >> > > >> > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> > >> Responses in-line: >> > >> >> > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau >> > wrote: >> > >>> >> > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> > >>>> In terms of CDI and EJB alignment, I think these would have the most >> > >>>> value to the community going forward: >> > >>>> >> > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >> > >>>> similarly nice syntax to handle eager loading). >> > >>> >> > >>> @Startup is there with @Initialized(ApplicationScoped) event >> > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> > >>> and full of proxies so not sure it would bring much to the game >> > >>> without bringing really much more like @Schedule etc... >> > >> >> > >> Yes, I know but eager loading is a common enough case to warrant better >> > syntax/usability. >> > > >> > > fair enough >> > > >> > >>> >> > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for >> > CDI. >> > >>>> These are very useful bits of functionality that should be available >> > to >> > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >> > >>>> extremely useful. EJB @Schedule is similarly useful but likely not >> > right >> > >>>> for CDI proper as it does not have that much to do with component >> > >>>> life-cycle/bean access management. The others I think are quite >> > natural >> > >>>> fits for the core of a DI framework (in fact it may be awkward to have >> > >>>> them elsewhere). >> > >>> >> > >>> >> > >>> Think concurrency utilities can have a CDI integration rather than >> > >>> putting everything in CDI. It is globally all interceptors - at least >> > >>> in term of design - so would make sense to have them outside IMO - but >> > >>> a big +1 to get them cleanly added on top of CDI. >> > >> >> > >> Keep in mind, Java EE concurrency utilities is also minimally resourced >> > and that's unlikely to change in the future. I would say if we think these >> > features would help community/CDI adoption, it's likely wisest to find a >> > way to do it in CDI proper. As I alluded to, these are also a bit easier to >> > implement at the core DI container level than via interceptors. Things like >> > @Transcational, @Schedule are easier as interceptors since they don't have >> > as much to do with the internals of the component life-cycle and instance >> > access control. >> > > >> > > well yes and not, it would be awesome to control where the concurrency >> > > is exactly in the stack and it would mean being able to change >> > > @Priority for instance. >> > > >> > > Overall point being that if we put features only where resources are >> > > instead of trying to put them where they fit and try to help these >> > > specs CDI will likely handle javascript integration soon ;). >> > > >> > > Concurrency and throttling have a potential spec which would be >> > > welcomed in these very distributed days, we just need to find people >> > > motivated enough to make it moving forward IMO. >> > > >> > >>> >> > >>>> >> > >>>> As to doing more work in EJB, honestly it's likely best to leave EJB >> > be >> > >>>> at this stage. If there is a compelling reason that helps the platform >> > >>>> and CDI generally we can see if it can be done. By default, EJB is >> > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >> > >>>> change at this stage. In the community I have mostly seen requests for >> > >>>> moving functionality out of EJB into CDI rather than the other way >> > around... >> > >>>> >> > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> > >>>>> Hi! >> > >>>>> >> > >>>>> We already do a decent amount of ?side-by-side? handling in EJB and >> > CDI. But there are still many aready where we could really move together >> > much closer. >> > >>>>> >> > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted by >> > the EJB container. But what happens with ProcessAnnotatedType#veto(). This >> > one is not defined that clearly I fear. >> > >>>>> >> > >>>>> What if we (of course together with the EJB spec group) define that >> > the EJB container must create the EJBs according to the effective >> > AnnotatedType coming out after ProcessAnnotatedType? This would define that >> > EJBs can also get modified via CDI Extensions. Some container do that >> > already. >> > >>>>> The benefit of explicitly writing this down would obviously be that >> > we would allow EJB to fully utilize the power of CDI Extensions in a >> > portable way. >> > >>>>> >> > >>>>> Any objections, any ideas, any howtos? >> > >>>>> >> > >>>>> Let the ideas roll ;) >> > >>>>> >> > >>>>> LieGrue, >> > >>>>> strub >> > >>>>> _______________________________________________ >> > >>>>> cdi-dev mailing list >> > >>>>> cdi-dev at lists.jboss.org >> > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >>>>> >> > >>>>> Note that for all code provided on this list, the provider licenses >> > the code under the Apache License, Version 2 ( >> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > provided on this list, the provider waives all patent and other >> > intellectual property rights inherent in such information. >> > >>>> >> > >>>> _______________________________________________ >> > >>>> cdi-dev mailing list >> > >>>> cdi-dev at lists.jboss.org >> > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >>>> >> > >>>> Note that for all code provided on this list, the provider licenses >> > the code under the Apache License, Version 2 ( >> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > provided on this list, the provider waives all patent and other >> > intellectual property rights inherent in such information. >> > >> > >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Tue, 17 Nov 2015 14:44:35 +0100 >> > From: Antonio Goncalves >> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> > To: Reza Rahman >> > Cc: "cdi-dev at lists.jboss.org" >> > Message-ID: >> > < >> > CA+ZZq98nGkMYUj5uEt7UuGHFcttdoi7zTiH_mWK5n_9zy2EaNQ at mail.gmail.com> >> > Content-Type: text/plain; charset="utf-8" >> > >> > HI all, >> > >> > This discussion comes back on and off. >> > >> > At the last F2F meeting, we talked about having @Startup and @Shutdown in >> > JSR 250. Talking to Bill and Linda, they don't seem reluctant to update the >> > spec. No need to have @DependsOn as we will use @Priority with @Startup. >> > >> > @Schedule should go to Java EE Concurrency (implemented as a CDI >> > interceptor) but not in CDI as this would be just moving more stuff inside >> > CDI (which will end up as big as EJBs). Same for @Asynchronous. >> > >> > So what could be doable in CDI 2.1 is having @Startup and @Shutdown >> > implemented... but the annotations would be in JSR 250. >> > >> > Antonio >> > >> > >> > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman >> > wrote: >> > >> > > One good thing is that Oracle has not yet filed a JSR for Java EE >> > > concurrency utilities targeting Java EE 8. That means any interested >> > > parties could do so and perhaps that could be better for the community in >> > > the end anyway. >> > > >> > > Certainly starting prototyping some of these things will make it clearer >> > > where they belong or could be contributed to in the end. >> > > >> > > > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau > > > >> > > wrote: >> > > > >> > > > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> > > >> Responses in-line: >> > > >> >> > > >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < >> > rmannibucau at gmail.com> >> > > wrote: >> > > >>> >> > > >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> > > >>>> In terms of CDI and EJB alignment, I think these would have the most >> > > >>>> value to the community going forward: >> > > >>>> >> > > >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core has >> > > >>>> similarly nice syntax to handle eager loading). >> > > >>> >> > > >>> @Startup is there with @Initialized(ApplicationScoped) event >> > > >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> > > >>> and full of proxies so not sure it would bring much to the game >> > > >>> without bringing really much more like @Schedule etc... >> > > >> >> > > >> Yes, I know but eager loading is a common enough case to warrant >> > better >> > > syntax/usability. >> > > > >> > > > fair enough >> > > > >> > > >>> >> > > >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for >> > > CDI. >> > > >>>> These are very useful bits of functionality that should be available >> > > to >> > > >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also be >> > > >>>> extremely useful. EJB @Schedule is similarly useful but likely not >> > > right >> > > >>>> for CDI proper as it does not have that much to do with component >> > > >>>> life-cycle/bean access management. The others I think are quite >> > > natural >> > > >>>> fits for the core of a DI framework (in fact it may be awkward to >> > have >> > > >>>> them elsewhere). >> > > >>> >> > > >>> >> > > >>> Think concurrency utilities can have a CDI integration rather than >> > > >>> putting everything in CDI. It is globally all interceptors - at least >> > > >>> in term of design - so would make sense to have them outside IMO - >> > but >> > > >>> a big +1 to get them cleanly added on top of CDI. >> > > >> >> > > >> Keep in mind, Java EE concurrency utilities is also minimally >> > resourced >> > > and that's unlikely to change in the future. I would say if we think >> > these >> > > features would help community/CDI adoption, it's likely wisest to find a >> > > way to do it in CDI proper. As I alluded to, these are also a bit easier >> > to >> > > implement at the core DI container level than via interceptors. Things >> > like >> > > @Transcational, @Schedule are easier as interceptors since they don't >> > have >> > > as much to do with the internals of the component life-cycle and instance >> > > access control. >> > > > >> > > > well yes and not, it would be awesome to control where the concurrency >> > > > is exactly in the stack and it would mean being able to change >> > > > @Priority for instance. >> > > > >> > > > Overall point being that if we put features only where resources are >> > > > instead of trying to put them where they fit and try to help these >> > > > specs CDI will likely handle javascript integration soon ;). >> > > > >> > > > Concurrency and throttling have a potential spec which would be >> > > > welcomed in these very distributed days, we just need to find people >> > > > motivated enough to make it moving forward IMO. >> > > > >> > > >>> >> > > >>>> >> > > >>>> As to doing more work in EJB, honestly it's likely best to leave EJB >> > > be >> > > >>>> at this stage. If there is a compelling reason that helps the >> > platform >> > > >>>> and CDI generally we can see if it can be done. By default, EJB is >> > > >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >> > > >>>> change at this stage. In the community I have mostly seen requests >> > for >> > > >>>> moving functionality out of EJB into CDI rather than the other way >> > > around... >> > > >>>> >> > > >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> > > >>>>> Hi! >> > > >>>>> >> > > >>>>> We already do a decent amount of ?side-by-side? handling in EJB and >> > > CDI. But there are still many aready where we could really move together >> > > much closer. >> > > >>>>> >> > > >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted >> > by >> > > the EJB container. But what happens with ProcessAnnotatedType#veto(). >> > This >> > > one is not defined that clearly I fear. >> > > >>>>> >> > > >>>>> What if we (of course together with the EJB spec group) define that >> > > the EJB container must create the EJBs according to the effective >> > > AnnotatedType coming out after ProcessAnnotatedType? This would define >> > that >> > > EJBs can also get modified via CDI Extensions. Some container do that >> > > already. >> > > >>>>> The benefit of explicitly writing this down would obviously be that >> > > we would allow EJB to fully utilize the power of CDI Extensions in a >> > > portable way. >> > > >>>>> >> > > >>>>> Any objections, any ideas, any howtos? >> > > >>>>> >> > > >>>>> Let the ideas roll ;) >> > > >>>>> >> > > >>>>> LieGrue, >> > > >>>>> strub >> > > >>>>> _______________________________________________ >> > > >>>>> cdi-dev mailing list >> > > >>>>> cdi-dev at lists.jboss.org >> > > >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >>>>> >> > > >>>>> Note that for all code provided on this list, the provider licenses >> > > the code under the Apache License, Version 2 ( >> > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > > provided on this list, the provider waives all patent and other >> > > intellectual property rights inherent in such information. >> > > >>>> >> > > >>>> _______________________________________________ >> > > >>>> cdi-dev mailing list >> > > >>>> cdi-dev at lists.jboss.org >> > > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >>>> >> > > >>>> Note that for all code provided on this list, the provider licenses >> > > the code under the Apache License, Version 2 ( >> > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > > provided on this list, the provider waives all patent and other >> > > intellectual property rights inherent in such information. >> > > >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >> > > Note that for all code provided on this list, the provider licenses the >> > > code under the Apache License, Version 2 ( >> > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > > provided on this list, the provider waives all patent and other >> > > intellectual property rights inherent in such information. >> > > >> > >> > >> > >> > -- >> > Antonio Goncalves >> > Software architect, Java Champion and Pluralsight author >> > >> > Web site | Twitter >> > | LinkedIn < >> > http://www.linkedin.com/in/agoncal> | >> > Pluralsight >> > | >> > Paris >> > JUG | Devoxx France >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: >> > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/3399b142/attachment-0001.html >> > >> > ------------------------------ >> > >> > Message: 3 >> > Date: Tue, 17 Nov 2015 15:03:32 +0100 >> > From: arjan tijms >> > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> > To: Antonio Goncalves >> > Cc: "cdi-dev at lists.jboss.org" >> > Message-ID: >> > > > AhAhn2W-yvJgGHQdv7PNS2jjGbJouxNirYOKyekuy9s3mQ at mail.gmail.com> >> > Content-Type: text/plain; charset="utf-8" >> > >> > Hi, >> > >> > On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < >> > antonio.goncalves at gmail.com> wrote: >> > >> > > @Schedule should go to Java EE Concurrency (implemented as a CDI >> > > interceptor) but not in CDI as this would be just moving more stuff >> > inside >> > > CDI (which will end up as big as EJBs). Same for @Asynchronous. >> > > >> > >> > 100% agree with this. It's almost better not to do things if absolutely >> > needed, then burden CDI with some concerns it perhaps should not be >> > concerned with. It's already problematic that CDI crossed this bridge once >> > with providing a Bean for Servlet and other artifacts it doesn't own. >> > >> > As for @Asynchronous, a basic prototype implementation has already been >> > created by several parties. I did one here: >> > http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld >> > team >> > did one here: >> > >> > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java >> > >> > Also interesting would be to go a little beyond what the EJB vesion offers >> > and add support for a completable feature and optionally named thread >> > pools. >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > >> > >> > > >> > > So what could be doable in CDI 2.1 is having @Startup and @Shutdown >> > > implemented... but the annotations would be in JSR 250. >> > > >> > > Antonio >> > > >> > > >> > > On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman >> > > wrote: >> > > >> > >> One good thing is that Oracle has not yet filed a JSR for Java EE >> > >> concurrency utilities targeting Java EE 8. That means any interested >> > >> parties could do so and perhaps that could be better for the community >> > in >> > >> the end anyway. >> > >> >> > >> Certainly starting prototyping some of these things will make it clearer >> > >> where they belong or could be contributed to in the end. >> > >> >> > >> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau < >> > rmannibucau at gmail.com> >> > >> wrote: >> > >> > >> > >> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> > >> >> Responses in-line: >> > >> >> >> > >> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < >> > >> rmannibucau at gmail.com> wrote: >> > >> >>> >> > >> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> > >> >>>> In terms of CDI and EJB alignment, I think these would have the >> > most >> > >> >>>> value to the community going forward: >> > >> >>>> >> > >> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core >> > has >> > >> >>>> similarly nice syntax to handle eager loading). >> > >> >>> >> > >> >>> @Startup is there with @Initialized(ApplicationScoped) event >> > >> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy >> > >> >>> and full of proxies so not sure it would bring much to the game >> > >> >>> without bringing really much more like @Schedule etc... >> > >> >> >> > >> >> Yes, I know but eager loading is a common enough case to warrant >> > >> better syntax/usability. >> > >> > >> > >> > fair enough >> > >> > >> > >> >>> >> > >> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout for >> > >> CDI. >> > >> >>>> These are very useful bits of functionality that should be >> > available >> > >> to >> > >> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also >> > be >> > >> >>>> extremely useful. EJB @Schedule is similarly useful but likely not >> > >> right >> > >> >>>> for CDI proper as it does not have that much to do with component >> > >> >>>> life-cycle/bean access management. The others I think are quite >> > >> natural >> > >> >>>> fits for the core of a DI framework (in fact it may be awkward to >> > >> have >> > >> >>>> them elsewhere). >> > >> >>> >> > >> >>> >> > >> >>> Think concurrency utilities can have a CDI integration rather than >> > >> >>> putting everything in CDI. It is globally all interceptors - at >> > least >> > >> >>> in term of design - so would make sense to have them outside IMO - >> > but >> > >> >>> a big +1 to get them cleanly added on top of CDI. >> > >> >> >> > >> >> Keep in mind, Java EE concurrency utilities is also minimally >> > >> resourced and that's unlikely to change in the future. I would say if we >> > >> think these features would help community/CDI adoption, it's likely >> > wisest >> > >> to find a way to do it in CDI proper. As I alluded to, these are also a >> > bit >> > >> easier to implement at the core DI container level than via >> > interceptors. >> > >> Things like @Transcational, @Schedule are easier as interceptors since >> > they >> > >> don't have as much to do with the internals of the component life-cycle >> > and >> > >> instance access control. >> > >> > >> > >> > well yes and not, it would be awesome to control where the concurrency >> > >> > is exactly in the stack and it would mean being able to change >> > >> > @Priority for instance. >> > >> > >> > >> > Overall point being that if we put features only where resources are >> > >> > instead of trying to put them where they fit and try to help these >> > >> > specs CDI will likely handle javascript integration soon ;). >> > >> > >> > >> > Concurrency and throttling have a potential spec which would be >> > >> > welcomed in these very distributed days, we just need to find people >> > >> > motivated enough to make it moving forward IMO. >> > >> > >> > >> >>> >> > >> >>>> >> > >> >>>> As to doing more work in EJB, honestly it's likely best to leave >> > EJB >> > >> be >> > >> >>>> at this stage. If there is a compelling reason that helps the >> > >> platform >> > >> >>>> and CDI generally we can see if it can be done. By default, EJB is >> > >> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to >> > >> >>>> change at this stage. In the community I have mostly seen requests >> > >> for >> > >> >>>> moving functionality out of EJB into CDI rather than the other way >> > >> around... >> > >> >>>> >> > >> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> > >> >>>>> Hi! >> > >> >>>>> >> > >> >>>>> We already do a decent amount of ?side-by-side? handling in EJB >> > and >> > >> CDI. But there are still many aready where we could really move together >> > >> much closer. >> > >> >>>>> >> > >> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get accounted >> > >> by the EJB container. But what happens with ProcessAnnotatedType#veto(). >> > >> This one is not defined that clearly I fear. >> > >> >>>>> >> > >> >>>>> What if we (of course together with the EJB spec group) define >> > that >> > >> the EJB container must create the EJBs according to the effective >> > >> AnnotatedType coming out after ProcessAnnotatedType? This would define >> > that >> > >> EJBs can also get modified via CDI Extensions. Some container do that >> > >> already. >> > >> >>>>> The benefit of explicitly writing this down would obviously be >> > that >> > >> we would allow EJB to fully utilize the power of CDI Extensions in a >> > >> portable way. >> > >> >>>>> >> > >> >>>>> Any objections, any ideas, any howtos? >> > >> >>>>> >> > >> >>>>> Let the ideas roll ;) >> > >> >>>>> >> > >> >>>>> LieGrue, >> > >> >>>>> strub >> > >> >>>>> _______________________________________________ >> > >> >>>>> cdi-dev mailing list >> > >> >>>>> cdi-dev at lists.jboss.org >> > >> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> >>>>> >> > >> >>>>> Note that for all code provided on this list, the provider >> > licenses >> > >> the code under the Apache License, Version 2 ( >> > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > >> provided on this list, the provider waives all patent and other >> > >> intellectual property rights inherent in such information. >> > >> >>>> >> > >> >>>> _______________________________________________ >> > >> >>>> cdi-dev mailing list >> > >> >>>> cdi-dev at lists.jboss.org >> > >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> >>>> >> > >> >>>> Note that for all code provided on this list, the provider licenses >> > >> the code under the Apache License, Version 2 ( >> > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > >> provided on this list, the provider waives all patent and other >> > >> intellectual property rights inherent in such information. >> > >> >> > >> _______________________________________________ >> > >> cdi-dev mailing list >> > >> cdi-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> >> > >> Note that for all code provided on this list, the provider licenses the >> > >> code under the Apache License, Version 2 ( >> > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > >> provided on this list, the provider waives all patent and other >> > >> intellectual property rights inherent in such information. >> > >> >> > > >> > > >> > > >> > > -- >> > > Antonio Goncalves >> > > Software architect, Java Champion and Pluralsight author >> > > >> > > Web site | Twitter >> > > | LinkedIn >> > > | Pluralsight >> > > | >> > Paris >> > > JUG | Devoxx France >> > > >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >> > > Note that for all code provided on this list, the provider licenses the >> > > code under the Apache License, Version 2 ( >> > > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > > provided on this list, the provider waives all patent and other >> > > intellectual property rights inherent in such information. >> > > >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: >> > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/c074f5ae/attachment.html >> > >> > ------------------------------ >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the >> > code under the Apache License, Version 2 ( >> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> > provided on this list, the provider waives all patent and other >> > intellectual property rights inherent in such information. >> > >> > End of cdi-dev Digest, Vol 60, Issue 13 >> > *************************************** >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/b1fb79c2/attachment.html >> >> ------------------------------ >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> End of cdi-dev Digest, Vol 60, Issue 14 >> *************************************** > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/268ddbed/attachment-0001.html From werner.keil at gmail.com Tue Nov 17 09:41:44 2015 From: werner.keil at gmail.com (Werner Keil) Date: Tue, 17 Nov 2015 15:41:44 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB Message-ID: Guess that isn't too different from touchpoints and possible needs to actually make minor changes to that spec with JSR 330 (aka @Inject ;-) If either for 330 or 236 changes to that actual spec are minimal, then it could be an overkill to file a new JSR just for the sake of it, a MR might be more than enough. Otherwise, maybe others including e.g. candidates for current EC seats could feel motivated enough to give it a try and offer themselves for such Spec Lead role. This year's JCP Award were since 2010 the first time that only Individuals (Adam Bien) and JSRs where at least Oracle isn't even in the EG (354/Anatole and 363 as well as JUG Chennai) won all awards. Maybe that could encourage Independent or smaller members, too?;-) Werner On Tue, Nov 17, 2015 at 1:58 PM, wrote: > Send cdi-dev mailing list submissions to > cdi-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/cdi-dev > or, via email, send a message with subject or body 'help' to > cdi-dev-request at lists.jboss.org > > You can reach the person managing the list at > cdi-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cdi-dev digest..." > > > Today's Topics: > > 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) > 2. Re: [PROPOSAL] further align CDI and EJB (Werner Keil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 17 Nov 2015 09:24:31 -0500 > From: Reza Rahman > Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB > To: "cdi-dev at lists.jboss.org" > Message-ID: <39F78EFC-0E6D-4AAA-B81B-BF00DF9FBD74 at oracle.com> > Content-Type: text/plain; charset="utf-8" > > I would encourage finding a way to contribute this work to a Java EE > specification (CDI or otherwise) while being aware of the resource > realities. > > It does not necessarily need to be done in the short term since Java EE > does have something after all from a purely functional standpoint. > > Adding completable future to @Asynchronous is definitely an obvious > improvement at this stage. I am trying to get that done for EJB if I at all > can. I think a contribution in the GF 5 branch accomplishing that in EJB > would be incredibly beneficial if time permits. I could then take care of > the TCK and spec text portions. > > > On Nov 17, 2015, at 9:03 AM, arjan tijms wrote: > > > > Hi, > > > >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < > antonio.goncalves at gmail.com> wrote: > >> @Schedule should go to Java EE Concurrency (implemented as a CDI > interceptor) but not in CDI as this would be just moving more stuff inside > CDI (which will end up as big as EJBs). Same for @Asynchronous. > > > > 100% agree with this. It's almost better not to do things if absolutely > needed, then burden CDI with some concerns it perhaps should not be > concerned with. It's already problematic that CDI crossed this bridge once > with providing a Bean for Servlet and other artifacts it doesn't own. > > > > As for @Asynchronous, a basic prototype implementation has already been > created by several parties. I did one here: > http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld > team did one here: > https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java > > > > Also interesting would be to go a little beyond what the EJB vesion > offers and add support for a completable feature and optionally named > thread pools. > > > > Kind regards, > > Arjan Tijms > > > > > > > >> > >> So what could be doable in CDI 2.1 is having @Startup and @Shutdown > implemented... but the annotations would be in JSR 250. > >> > >> Antonio > >> > >> > >>> On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman > wrote: > >>> One good thing is that Oracle has not yet filed a JSR for Java EE > concurrency utilities targeting Java EE 8. That means any interested > parties could do so and perhaps that could be better for the community in > the end anyway. > >>> > >>> Certainly starting prototyping some of these things will make it > clearer where they belong or could be contributed to in the end. > >>> > >>> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>> > > >>> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : > >>> >> Responses in-line: > >>> >> > >>> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < > rmannibucau at gmail.com> wrote: > >>> >>> > >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : > >>> >>>> In terms of CDI and EJB alignment, I think these would have the > most > >>> >>>> value to the community going forward: > >>> >>>> > >>> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core > has > >>> >>>> similarly nice syntax to handle eager loading). > >>> >>> > >>> >>> @Startup is there with @Initialized(ApplicationScoped) event > >>> >>> @DependsOn is less important than for EJB IMO cause all CDI is lazy > >>> >>> and full of proxies so not sure it would bring much to the game > >>> >>> without bringing really much more like @Schedule etc... > >>> >> > >>> >> Yes, I know but eager loading is a common enough case to warrant > better syntax/usability. > >>> > > >>> > fair enough > >>> > > >>> >>> > >>> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout > for CDI. > >>> >>>> These are very useful bits of functionality that should be > available to > >>> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could also > be > >>> >>>> extremely useful. EJB @Schedule is similarly useful but likely > not right > >>> >>>> for CDI proper as it does not have that much to do with component > >>> >>>> life-cycle/bean access management. The others I think are quite > natural > >>> >>>> fits for the core of a DI framework (in fact it may be awkward to > have > >>> >>>> them elsewhere). > >>> >>> > >>> >>> > >>> >>> Think concurrency utilities can have a CDI integration rather than > >>> >>> putting everything in CDI. It is globally all interceptors - at > least > >>> >>> in term of design - so would make sense to have them outside IMO - > but > >>> >>> a big +1 to get them cleanly added on top of CDI. > >>> >> > >>> >> Keep in mind, Java EE concurrency utilities is also minimally > resourced and that's unlikely to change in the future. I would say if we > think these features would help community/CDI adoption, it's likely wisest > to find a way to do it in CDI proper. As I alluded to, these are also a bit > easier to implement at the core DI container level than via interceptors. > Things like @Transcational, @Schedule are easier as interceptors since they > don't have as much to do with the internals of the component life-cycle and > instance access control. > >>> > > >>> > well yes and not, it would be awesome to control where the > concurrency > >>> > is exactly in the stack and it would mean being able to change > >>> > @Priority for instance. > >>> > > >>> > Overall point being that if we put features only where resources are > >>> > instead of trying to put them where they fit and try to help these > >>> > specs CDI will likely handle javascript integration soon ;). > >>> > > >>> > Concurrency and throttling have a potential spec which would be > >>> > welcomed in these very distributed days, we just need to find people > >>> > motivated enough to make it moving forward IMO. > >>> > > >>> >>> > >>> >>>> > >>> >>>> As to doing more work in EJB, honestly it's likely best to leave > EJB be > >>> >>>> at this stage. If there is a compelling reason that helps the > platform > >>> >>>> and CDI generally we can see if it can be done. By default, EJB is > >>> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard to > >>> >>>> change at this stage. In the community I have mostly seen > requests for > >>> >>>> moving functionality out of EJB into CDI rather than the other > way around... > >>> >>>> > >>> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: > >>> >>>>> Hi! > >>> >>>>> > >>> >>>>> We already do a decent amount of ?side-by-side? handling in EJB > and CDI. But there are still many aready where we could really move > together much closer. > >>> >>>>> > >>> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get > accounted by the EJB container. But what happens with > ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. > >>> >>>>> > >>> >>>>> What if we (of course together with the EJB spec group) define > that the EJB container must create the EJBs according to the effective > AnnotatedType coming out after ProcessAnnotatedType? This would define that > EJBs can also get modified via CDI Extensions. Some container do that > already. > >>> >>>>> The benefit of explicitly writing this down would obviously be > that we would allow EJB to fully utilize the power of CDI Extensions in a > portable way. > >>> >>>>> > >>> >>>>> Any objections, any ideas, any howtos? > >>> >>>>> > >>> >>>>> Let the ideas roll ;) > >>> >>>>> > >>> >>>>> LieGrue, > >>> >>>>> strub > >>> >>>>> _______________________________________________ > >>> >>>>> cdi-dev mailing list > >>> >>>>> cdi-dev at lists.jboss.org > >>> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> >>>>> > >>> >>>>> Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>> >>>> > >>> >>>> _______________________________________________ > >>> >>>> cdi-dev mailing list > >>> >>>> cdi-dev at lists.jboss.org > >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> >>>> > >>> >>>> Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>> > >>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >> > >> > >> > >> -- > >> Antonio Goncalves > >> Software architect, Java Champion and Pluralsight author > >> > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/98382c30/attachment-0001.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/5306735e/attachment-0001.html From stephan at knitelius.com Wed Nov 18 16:47:49 2015 From: stephan at knitelius.com (Stephan Knitelius) Date: Wed, 18 Nov 2015 21:47:49 +0000 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB In-Reply-To: References: Message-ID: I think it would be better to integrate concurrency handling into CDI, to avoid further ambiguities that will arise when dealing with separate specifications. Introduction of @Lock would allow concurrency control on contextual beans. This would make life a lot easier especially when dealing with AJAX applications, which often fire concurrent requests. Such as in the case of JSF AJAX applications, at the moment concurrent access is handled by the JSF implementation, easier immediately throwing a BusyConversationException or waiting for a couple of milliseconds before retrying. Stephan On Tue, 17 Nov 2015 at 15:42 Werner Keil wrote: > Guess that isn't too different from touchpoints and possible needs to > actually make minor changes to that spec with JSR 330 (aka @Inject ;-) > > If either for 330 or 236 changes to that actual spec are minimal, then it > could be an overkill to file a new JSR just for the sake of it, a MR might > be more than enough. > > Otherwise, maybe others including e.g. candidates for current EC seats > could feel motivated enough to give it a try and offer themselves for such > Spec Lead role. > > This year's JCP Award were since 2010 the first time that only Individuals > (Adam Bien) and JSRs where at least Oracle isn't even in the EG > (354/Anatole and 363 as well as JUG Chennai) won all awards. Maybe that > could encourage Independent or smaller members, too?;-) > > Werner > > On Tue, Nov 17, 2015 at 1:58 PM, wrote: > >> Send cdi-dev mailing list submissions to >> cdi-dev at lists.jboss.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> or, via email, send a message with subject or body 'help' to >> cdi-dev-request at lists.jboss.org >> >> You can reach the person managing the list at >> cdi-dev-owner at lists.jboss.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of cdi-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) >> > 2. Re: [PROPOSAL] further align CDI and EJB (Werner Keil) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 17 Nov 2015 09:24:31 -0500 > > >> From: Reza Rahman >> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >> To: "cdi-dev at lists.jboss.org" >> > Message-ID: <39F78EFC-0E6D-4AAA-B81B-BF00DF9FBD74 at oracle.com> >> Content-Type: text/plain; charset="utf-8" > > >> >> I would encourage finding a way to contribute this work to a Java EE >> specification (CDI or otherwise) while being aware of the resource >> realities. >> >> It does not necessarily need to be done in the short term since Java EE >> does have something after all from a purely functional standpoint. >> >> Adding completable future to @Asynchronous is definitely an obvious >> improvement at this stage. I am trying to get that done for EJB if I at all >> can. I think a contribution in the GF 5 branch accomplishing that in EJB >> would be incredibly beneficial if time permits. I could then take care of >> the TCK and spec text portions. >> >> > On Nov 17, 2015, at 9:03 AM, arjan tijms wrote: >> > >> > > Hi, >> > >> >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < >> antonio.goncalves at gmail.com> wrote: >> >> @Schedule should go to Java EE Concurrency (implemented as a CDI >> interceptor) but not in CDI as this would be just moving more stuff inside >> CDI (which will end up as big as EJBs). Same for @Asynchronous. >> > >> > 100% agree with this. It's almost better not to do things if absolutely >> needed, then burden CDI with some concerns it perhaps should not be >> concerned with. It's already problematic that CDI crossed this bridge once >> with providing a Bean for Servlet and other artifacts it doesn't own. >> > >> > As for @Asynchronous, a basic prototype implementation has already been >> created by several parties. I did one here: >> http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld >> team did one here: >> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java >> > >> > Also interesting would be to go a little beyond what the EJB vesion >> offers and add support for a completable feature and optionally named >> thread pools. >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > >> >> >> >> So what could be doable in CDI 2.1 is having @Startup and @Shutdown >> implemented... but the annotations would be in JSR 250. >> >> >> >> Antonio >> >> >> >> >> >>> On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman >> wrote: >> >>> One good thing is that Oracle has not yet filed a JSR for Java EE >> concurrency utilities targeting Java EE 8. That means any interested >> parties could do so and perhaps that could be better for the community in >> the end anyway. >> >>> >> >>> Certainly starting prototyping some of these things will make it >> clearer where they belong or could be contributed to in the end. >> >>> >> >>> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>> > >> >>> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >> >>> >> Responses in-line: >> >>> >> >> >>> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < >> rmannibucau at gmail.com> wrote: >> >>> >>> >> >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >> >>> >>>> In terms of CDI and EJB alignment, I think these would have the >> most >> >>> >>>> value to the community going forward: >> >>> >>>> >> >>> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring core >> has >> >>> >>>> similarly nice syntax to handle eager loading). >> >>> >>> >> >>> >>> @Startup is there with @Initialized(ApplicationScoped) event >> >>> >>> @DependsOn is less important than for EJB IMO cause all CDI is >> lazy >> >>> >>> and full of proxies so not sure it would bring much to the game >> >>> >>> without bringing really much more like @Schedule etc... >> >>> >> >> >>> >> Yes, I know but eager loading is a common enough case to warrant >> better syntax/usability. >> >>> > >> >>> > fair enough >> >>> > >> >>> >>> >> >>> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout >> for CDI. >> >>> >>>> These are very useful bits of functionality that should be >> available to >> >>> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could >> also be >> >>> >>>> extremely useful. EJB @Schedule is similarly useful but likely >> not right >> >>> >>>> for CDI proper as it does not have that much to do with component >> >>> >>>> life-cycle/bean access management. The others I think are quite >> natural >> >>> >>>> fits for the core of a DI framework (in fact it may be awkward >> to have >> >>> >>>> them elsewhere). >> >>> >>> >> >>> >>> >> >>> >>> Think concurrency utilities can have a CDI integration rather than >> >>> >>> putting everything in CDI. It is globally all interceptors - at >> least >> >>> >>> in term of design - so would make sense to have them outside IMO >> - but >> >>> >>> a big +1 to get them cleanly added on top of CDI. >> >>> >> >> >>> >> Keep in mind, Java EE concurrency utilities is also minimally >> resourced and that's unlikely to change in the future. I would say if we >> think these features would help community/CDI adoption, it's likely wisest >> to find a way to do it in CDI proper. As I alluded to, these are also a bit >> easier to implement at the core DI container level than via interceptors. >> Things like @Transcational, @Schedule are easier as interceptors since they >> don't have as much to do with the internals of the component life-cycle and >> instance access control. >> >>> > >> >>> > well yes and not, it would be awesome to control where the >> concurrency >> >>> > is exactly in the stack and it would mean being able to change >> >>> > @Priority for instance. >> >>> > >> >>> > Overall point being that if we put features only where resources are >> >>> > instead of trying to put them where they fit and try to help these >> >>> > specs CDI will likely handle javascript integration soon ;). >> >>> > >> >>> > Concurrency and throttling have a potential spec which would be >> >>> > welcomed in these very distributed days, we just need to find people >> >>> > motivated enough to make it moving forward IMO. >> >>> > >> >>> >>> >> >>> >>>> >> >>> >>>> As to doing more work in EJB, honestly it's likely best to leave >> EJB be >> >>> >>>> at this stage. If there is a compelling reason that helps the >> platform >> >>> >>>> and CDI generally we can see if it can be done. By default, EJB >> is >> >>> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard >> to >> >>> >>>> change at this stage. In the community I have mostly seen >> requests for >> >>> >>>> moving functionality out of EJB into CDI rather than the other >> way around... >> >>> >>>> >> >>> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >> >>> >>>>> Hi! >> >>> >>>>> >> >>> >>>>> We already do a decent amount of ?side-by-side? handling in EJB >> and CDI. But there are still many aready where we could really move >> together much closer. >> >>> >>>>> >> >>> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get >> accounted by the EJB container. But what happens with >> ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >> >>> >>>>> >> >>> >>>>> What if we (of course together with the EJB spec group) define >> that the EJB container must create the EJBs according to the effective >> AnnotatedType coming out after ProcessAnnotatedType? This would define that >> EJBs can also get modified via CDI Extensions. Some container do that >> already. >> >>> >>>>> The benefit of explicitly writing this down would obviously be >> that we would allow EJB to fully utilize the power of CDI Extensions in a >> portable way. >> >>> >>>>> >> >>> >>>>> Any objections, any ideas, any howtos? >> >>> >>>>> >> >>> >>>>> Let the ideas roll ;) >> >>> >>>>> >> >>> >>>>> LieGrue, >> >>> >>>>> strub >> >>> >>>>> _______________________________________________ >> >>> >>>>> cdi-dev mailing list >> >>> >>>>> cdi-dev at lists.jboss.org >> >>> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>> >>>>> >> > >>> >>>>> Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >>> >>>> >> >>> >>>> _______________________________________________ >> >>> >>>> cdi-dev mailing list >> >>> >>>> cdi-dev at lists.jboss.org >> >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>> >>>> >> >>> >>>> Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >>> >> > >>> _______________________________________________ >> >>> cdi-dev mailing list >> >>> cdi-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>> >> >>> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> >> >> >> >> >> > >> -- >> >> Antonio Goncalves >> >> Software architect, Java Champion and Pluralsight author >> >> >> > >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France > > >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> > >> > -------------- next part -------------- >> An HTML attachment was scrubbed... >> > URL: >> http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/98382c30/attachment-0001.html >> >> _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151118/55bfbf0f/attachment-0001.html From werner.keil at gmail.com Wed Nov 18 16:55:17 2015 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 18 Nov 2015 22:55:17 +0100 Subject: [cdi-dev] [PROPOSAL] further align CDI and EJB Message-ID: Where it doesn't duplicate or reinvent something already defined in another spec there should be no problem with that. Werner On Wed, Nov 18, 2015 at 10:47 PM, Stephan Knitelius wrote: > I think it would be better to integrate concurrency handling into CDI, to > avoid further ambiguities that will arise when dealing with separate > specifications. > > Introduction of @Lock would allow concurrency control on contextual beans. > This would make life a lot easier especially when dealing with AJAX > applications, which often fire concurrent requests. Such as in the case of > JSF AJAX applications, at the moment concurrent access is handled by the > JSF implementation, easier immediately throwing a BusyConversationException > or waiting for a couple of milliseconds before retrying. > > Stephan > > On Tue, 17 Nov 2015 at 15:42 Werner Keil wrote: > >> Guess that isn't too different from touchpoints and possible needs to >> actually make minor changes to that spec with JSR 330 (aka @Inject ;-) >> >> If either for 330 or 236 changes to that actual spec are minimal, then it >> could be an overkill to file a new JSR just for the sake of it, a MR might >> be more than enough. >> >> Otherwise, maybe others including e.g. candidates for current EC seats >> could feel motivated enough to give it a try and offer themselves for such >> Spec Lead role. >> >> This year's JCP Award were since 2010 the first time that only >> Individuals (Adam Bien) and JSRs where at least Oracle isn't even in the EG >> (354/Anatole and 363 as well as JUG Chennai) won all awards. Maybe that >> could encourage Independent or smaller members, too?;-) >> >> Werner >> >> On Tue, Nov 17, 2015 at 1:58 PM, wrote: >> >>> Send cdi-dev mailing list submissions to >>> cdi-dev at lists.jboss.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> or, via email, send a message with subject or body 'help' to >>> cdi-dev-request at lists.jboss.org >>> >>> You can reach the person managing the list at >>> cdi-dev-owner at lists.jboss.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of cdi-dev digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: [PROPOSAL] further align CDI and EJB (Reza Rahman) >>> >> 2. Re: [PROPOSAL] further align CDI and EJB (Werner Keil) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Tue, 17 Nov 2015 09:24:31 -0500 >> >> >>> From: Reza Rahman >>> Subject: Re: [cdi-dev] [PROPOSAL] further align CDI and EJB >>> To: "cdi-dev at lists.jboss.org" >>> >> Message-ID: <39F78EFC-0E6D-4AAA-B81B-BF00DF9FBD74 at oracle.com> >>> Content-Type: text/plain; charset="utf-8" >> >> >>> >>> I would encourage finding a way to contribute this work to a Java EE >>> specification (CDI or otherwise) while being aware of the resource >>> realities. >>> >>> It does not necessarily need to be done in the short term since Java EE >>> does have something after all from a purely functional standpoint. >>> >>> Adding completable future to @Asynchronous is definitely an obvious >>> improvement at this stage. I am trying to get that done for EJB if I at all >>> can. I think a contribution in the GF 5 branch accomplishing that in EJB >>> would be incredibly beneficial if time permits. I could then take care of >>> the TCK and spec text portions. >>> >>> > On Nov 17, 2015, at 9:03 AM, arjan tijms >>> wrote: >>> > >>> >> > Hi, >>> > >>> >> On Tue, Nov 17, 2015 at 2:44 PM, Antonio Goncalves < >>> antonio.goncalves at gmail.com> wrote: >>> >> @Schedule should go to Java EE Concurrency (implemented as a CDI >>> interceptor) but not in CDI as this would be just moving more stuff inside >>> CDI (which will end up as big as EJBs). Same for @Asynchronous. >>> > >>> > 100% agree with this. It's almost better not to do things if >>> absolutely needed, then burden CDI with some concerns it perhaps should not >>> be concerned with. It's already problematic that CDI crossed this bridge >>> once with providing a Bean for Servlet and other artifacts it doesn't >>> own. >>> > >>> > As for @Asynchronous, a basic prototype implementation has already >>> been created by several parties. I did one here: >>> http://jdevelopment.nl/cdi-based-asynchronous-alternative and the Weld >>> team did one here: >>> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/thread/async/AsyncInterceptor.java >>> > >>> > Also interesting would be to go a little beyond what the EJB vesion >>> offers and add support for a completable feature and optionally named >>> thread pools. >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > >>> > >>> >> >>> >> So what could be doable in CDI 2.1 is having @Startup and @Shutdown >>> implemented... but the annotations would be in JSR 250. >>> >> >>> >> Antonio >>> >> >>> >> >>> >>> On Tue, Nov 17, 2015 at 12:55 AM, Reza Rahman < >>> reza.rahman at oracle.com> wrote: >>> >>> One good thing is that Oracle has not yet filed a JSR for Java EE >>> concurrency utilities targeting Java EE 8. That means any interested >>> parties could do so and perhaps that could be better for the community in >>> the end anyway. >>> >>> >>> >>> Certainly starting prototyping some of these things will make it >>> clearer where they belong or could be contributed to in the end. >>> >>> >>> >>> > On Nov 16, 2015, at 6:04 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>> > >>> >>> > 2015-11-16 14:54 GMT-08:00 Reza Rahman : >>> >>> >> Responses in-line: >>> >>> >> >>> >>> >>> On Nov 16, 2015, at 5:44 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>> >>> >>> >>> >>> 2015-11-16 14:40 GMT-08:00 Reza Rahman : >>> >>> >>>> In terms of CDI and EJB alignment, I think these would have the >>> most >>> >>> >>>> value to the community going forward: >>> >>> >>>> >>> >>> >>>> * The equivalent of EJB @Startup, @DependsOn in CDI (Spring >>> core has >>> >>> >>>> similarly nice syntax to handle eager loading). >>> >>> >>> >>> >>> >>> @Startup is there with @Initialized(ApplicationScoped) event >>> >>> >>> @DependsOn is less important than for EJB IMO cause all CDI is >>> lazy >>> >>> >>> and full of proxies so not sure it would bring much to the game >>> >>> >>> without bringing really much more like @Schedule etc... >>> >>> >> >>> >>> >> Yes, I know but eager loading is a common enough case to warrant >>> better syntax/usability. >>> >>> > >>> >>> > fair enough >>> >>> > >>> >>> >>> >>> >>> >>>> * The equivalent of EJB @Asynchronous, @Lock and @AccessTimeout >>> for CDI. >>> >>> >>>> These are very useful bits of functionality that should be >>> available to >>> >>> >>>> plain CDI beans without EJB. A similar @MaxConcurrency could >>> also be >>> >>> >>>> extremely useful. EJB @Schedule is similarly useful but likely >>> not right >>> >>> >>>> for CDI proper as it does not have that much to do with >>> component >>> >>> >>>> life-cycle/bean access management. The others I think are quite >>> natural >>> >>> >>>> fits for the core of a DI framework (in fact it may be awkward >>> to have >>> >>> >>>> them elsewhere). >>> >>> >>> >>> >>> >>> >>> >>> >>> Think concurrency utilities can have a CDI integration rather >>> than >>> >>> >>> putting everything in CDI. It is globally all interceptors - at >>> least >>> >>> >>> in term of design - so would make sense to have them outside IMO >>> - but >>> >>> >>> a big +1 to get them cleanly added on top of CDI. >>> >>> >> >>> >>> >> Keep in mind, Java EE concurrency utilities is also minimally >>> resourced and that's unlikely to change in the future. I would say if we >>> think these features would help community/CDI adoption, it's likely wisest >>> to find a way to do it in CDI proper. As I alluded to, these are also a bit >>> easier to implement at the core DI container level than via interceptors. >>> Things like @Transcational, @Schedule are easier as interceptors since they >>> don't have as much to do with the internals of the component life-cycle and >>> instance access control. >>> >>> > >>> >>> > well yes and not, it would be awesome to control where the >>> concurrency >>> >>> > is exactly in the stack and it would mean being able to change >>> >>> > @Priority for instance. >>> >>> > >>> >>> > Overall point being that if we put features only where resources >>> are >>> >>> > instead of trying to put them where they fit and try to help these >>> >>> > specs CDI will likely handle javascript integration soon ;). >>> >>> > >>> >>> > Concurrency and throttling have a potential spec which would be >>> >>> > welcomed in these very distributed days, we just need to find >>> people >>> >>> > motivated enough to make it moving forward IMO. >>> >>> > >>> >>> >>> >>> >>> >>>> >>> >>> >>>> As to doing more work in EJB, honestly it's likely best to >>> leave EJB be >>> >>> >>>> at this stage. If there is a compelling reason that helps the >>> platform >>> >>> >>>> and CDI generally we can see if it can be done. By default, EJB >>> is >>> >>> >>>> pretty minimally resourced for Java EE 8 and that's pretty hard >>> to >>> >>> >>>> change at this stage. In the community I have mostly seen >>> requests for >>> >>> >>>> moving functionality out of EJB into CDI rather than the other >>> way around... >>> >>> >>>> >>> >>> >>>>> On 11/11/2015 2:47 PM, Mark Struberg wrote: >>> >>> >>>>> Hi! >>> >>> >>>>> >>> >>> >>>>> We already do a decent amount of ?side-by-side? handling in >>> EJB and CDI. But there are still many aready where we could really move >>> together much closer. >>> >>> >>>>> >>> >>> >>>>> E.g. the CDI spec defines that @Vetoed on EJBs must get >>> accounted by the EJB container. But what happens with >>> ProcessAnnotatedType#veto(). This one is not defined that clearly I fear. >>> >>> >>>>> >>> >>> >>>>> What if we (of course together with the EJB spec group) define >>> that the EJB container must create the EJBs according to the effective >>> AnnotatedType coming out after ProcessAnnotatedType? This would define that >>> EJBs can also get modified via CDI Extensions. Some container do that >>> already. >>> >>> >>>>> The benefit of explicitly writing this down would obviously be >>> that we would allow EJB to fully utilize the power of CDI Extensions in a >>> portable way. >>> >>> >>>>> >>> >>> >>>>> Any objections, any ideas, any howtos? >>> >>> >>>>> >>> >>> >>>>> Let the ideas roll ;) >>> >>> >>>>> >>> >>> >>>>> LieGrue, >>> >>> >>>>> strub >>> >>> >>>>> _______________________________________________ >>> >>> >>>>> cdi-dev mailing list >>> >>> >>>>> cdi-dev at lists.jboss.org >>> >>> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> >>>>> >>> >> >>> >>>>> Note that for all code provided on this list, the provider >>> licenses the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> >>>> >>> >>> >>>> _______________________________________________ >>> >>> >>>> cdi-dev mailing list >>> >>> >>>> cdi-dev at lists.jboss.org >>> >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> >>>> >>> >>> >>>> Note that for all code provided on this list, the provider >>> licenses the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> >>> >> >>> _______________________________________________ >>> >>> cdi-dev mailing list >>> >>> cdi-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> >>> >>> Note that for all code provided on this list, the provider licenses >>> the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >> >>> >> >>> >> >>> >> >> -- >>> >> Antonio Goncalves >>> >> Software architect, Java Champion and Pluralsight author >>> >> >>> >> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France >> >> >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> >>> >> Note that for all code provided on this list, the provider licenses >>> the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> > >>> >> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> >> URL: >>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20151117/98382c30/attachment-0001.html >>> >>> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151118/045df69e/attachment-0001.html From emijiang6 at googlemail.com Thu Nov 19 05:09:47 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Thu, 19 Nov 2015 10:09:47 +0000 Subject: [cdi-dev] Clarification on 4.3 Specialization Message-ID: 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 at CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified My application failed deployment with the error on Weld but worked on OpenWebBeans [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) -- 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. I also checked the spec: @Alternative @Specializes public class MockAsynchronousService extends AsynchronousService { ... } 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. I would like to know what other people think. Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151119/8eb649d8/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: testDiffBDA.war Type: application/octet-stream Size: 7618 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20151119/8eb649d8/attachment.obj From emijiang6 at googlemail.com Sun Nov 22 16:42:29 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Sun, 22 Nov 2015 21:42:29 +0000 Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: References: Message-ID: any thoughts? Should a bean with @Specialize disable a bean even if it is disabled itself? On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang wrote: > > 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 at CounterModifiedQualifier String modifiedProducer; > > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > > My application failed deployment with the error on Weld but worked on > OpenWebBeans > > [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) > -- > > > 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. > > > I also checked the spec: > @Alternative @Specializes > public class MockAsynchronousService extends AsynchronousService { > ... > } > 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. I would > like to know what other people think. > > > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151122/262c87cc/attachment.html From tremes at redhat.com Mon Nov 23 02:33:44 2015 From: tremes at redhat.com (Tomas Remes) Date: Mon, 23 Nov 2015 02:33:44 -0500 (EST) Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: References: Message-ID: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> Hi Emily, I am not sure I follow. What is disabled? AlternativeCounterProducerModified? I can see AlternativeCounterProducerModified is enabled in beans.xml of the given bean archive and it means it is selected alternative only per the bean archive. So I can't see any problem (or maybe I don't fully understand). Tom ----- Original Message ----- From: "Emily Jiang" To: "cdi-dev" Sent: Sunday, November 22, 2015 10:42:29 PM Subject: Re: [cdi-dev] Clarification on 4.3 Specialization any thoughts? Should a bean with @Specialize disable a bean even if it is disabled itself? On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang < emijiang6 at googlemail.com > wrote: 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 at CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified My application failed deployment with the error on Weld but worked on OpenWebBeans [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) -- 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. I also checked the spec: @Alternative @Specializes public class MockAsynchronousService extends AsynchronousService { ... } 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. I would like to know what other people think. Thanks Emily ================= Emily Jiang ejiang at apache.org -- Thanks Emily ================= Emily Jiang ejiang at apache.org _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -- Tomas Remes From manovotn at redhat.com Mon Nov 23 03:45:19 2015 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 23 Nov 2015 03:45:19 -0500 (EST) Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> References: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> Message-ID: <735397814.15187222.1448268319886.JavaMail.zimbra@redhat.com> Hello Emily I agree with Tom. In your case, specialized producer is enabled (via beans.xml) although only per bean archive. And about this: >>From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. It is true, however the spec doesn't define how does a @Specialized bean behave when it is disabled (or at least I haven't found that bit). So this leaves it up to implementation and I can't really see a problem with it. Why would you create a @Specialized bean and disable it afterwards (with no other @Specialized and/or @Alternative active)? Matej ----- Original Message ----- From: "Tomas Remes" To: "Emily Jiang" Cc: "cdi-dev" Sent: Monday, November 23, 2015 8:33:44 AM Subject: Re: [cdi-dev] Clarification on 4.3 Specialization Hi Emily, I am not sure I follow. What is disabled? AlternativeCounterProducerModified? I can see AlternativeCounterProducerModified is enabled in beans.xml of the given bean archive and it means it is selected alternative only per the bean archive. So I can't see any problem (or maybe I don't fully understand). Tom ----- Original Message ----- From: "Emily Jiang" To: "cdi-dev" Sent: Sunday, November 22, 2015 10:42:29 PM Subject: Re: [cdi-dev] Clarification on 4.3 Specialization any thoughts? Should a bean with @Specialize disable a bean even if it is disabled itself? On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang < emijiang6 at googlemail.com > wrote: 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 at CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified My application failed deployment with the error on Weld but worked on OpenWebBeans [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) -- 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. I also checked the spec: @Alternative @Specializes public class MockAsynchronousService extends AsynchronousService { ... } 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. I would like to know what other people think. Thanks Emily ================= Emily Jiang ejiang at apache.org -- Thanks Emily ================= Emily Jiang ejiang at apache.org _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. -- Tomas Remes _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From issues at jboss.org Mon Nov 23 04:42:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 23 Nov 2015 04:42:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132494#comment-13132494 ] Antoine Sabot-Durand commented on CDI-10: ----------------------------------------- I think there are mixed needs here. And as we have tickets exposing similar needs (CDI-562, CDI-561and CDI-515), I think interesting to start from use cases. I see 2 of them (please add others if I missed one): # Getting class of the bean to "read" meta-data. IMO in this case accessing the class is not the best solution: meta-data may have been overridden and as section 11.4 states : {quote}The container must use the operations of Annotated and its subinterfaces to discover program element types and annotations. The container must not directly call the Java Reflection API{quote} # Getting the actual unwrap instance to have an unmanaged version of the instance (as described in CDI-561). But the use case are less obvious and the fact that other proxies may be injected in the instance make this rather hard to specify. If we focus on 1st use case (having a way to read meta-data). We have to provide a way to retrieve the {{Bean}} from the instance and add a way to easily discover the nature of a given {{Bean}} (managed bean, session, bean, producer, custom). Having this info will help user to know where to find meta-data... Regarding second point, every body interested should describe a user case from user POV to see if it's worth digging in that direction. > 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 > 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) From emijiang6 at googlemail.com Mon Nov 23 04:54:22 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 23 Nov 2015 09:54:22 +0000 Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: <735397814.15187222.1448268319886.JavaMail.zimbra@redhat.com> References: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> <735397814.15187222.1448268319886.JavaMail.zimbra@redhat.com> Message-ID: Thank you Tom and Matej for your response! The alternative was enabled in the archive beans-xml-modified.jar, but it is not enabled in the archive beans-xml-modified2.jar. The issue is not with alternative but with Specialized. At the moment, Weld specialized is effective even if itself is not enabled, which is not desirable because it disables other bean but itself is not enabled. As a consequence, this causes deployment error. The CDI 1.2 section 4.3 spec says: 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. It is true the above sentence comments about an enabled bean. It hits an disabled bean should not specialize a second bean. If you guys think it is unclear, can we update the spec to clarify this scenario? By the way, OWB and Weld behave differently (Weld thinks a disabled bean still specializes a second bean while OWB thinks a disabled bean does NOT specialize a second bean). This is something we can leave to implementation. We should spec it! On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny wrote: > Hello Emily > > I agree with Tom. In your case, specialized producer is enabled (via > beans.xml) although only per bean archive. > > > And about this: > >>From Weld's perspective, any bean annotated with @Specialized disables a > second bean regardless whether itself is active or not. > > It is true, however the spec doesn't define how does a @Specialized bean > behave when it is disabled (or at least I haven't found that bit). > So this leaves it up to implementation and I can't really see a problem > with it. Why would you create a @Specialized bean and disable it afterwards > (with no other @Specialized and/or @Alternative active)? > > > Matej > > ----- Original Message ----- > From: "Tomas Remes" > To: "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, November 23, 2015 8:33:44 AM > Subject: Re: [cdi-dev] Clarification on 4.3 Specialization > > > Hi Emily, > > I am not sure I follow. What is disabled? > AlternativeCounterProducerModified? I can see > AlternativeCounterProducerModified is enabled in beans.xml of the given > bean archive and it means it is selected alternative only per the bean > archive. So I can't see any problem (or maybe I don't fully understand). > > Tom > > ----- Original Message ----- > From: "Emily Jiang" > To: "cdi-dev" > Sent: Sunday, November 22, 2015 10:42:29 PM > Subject: Re: [cdi-dev] Clarification on 4.3 Specialization > > any thoughts? > > Should a bean with @Specialize disable a bean even if it is disabled > itself? > > On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang < emijiang6 at googlemail.com > > wrote: > > > > > 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 at CounterModifiedQualifier String modifiedProducer; > > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > > My application failed deployment with the error on Weld but worked on > OpenWebBeans > > [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) > -- > > > 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. > > > I also checked the spec: > @Alternative @Specializes > public class MockAsynchronousService extends AsynchronousService { > ... > } > 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. I would > like to know what other people think. > > > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > -- > Tomas Remes > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151123/849fa5e6/attachment.html From mkouba at redhat.com Mon Nov 23 05:06:35 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 23 Nov 2015 11:06:35 +0100 Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: References: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> <735397814.15187222.1448268319886.JavaMail.zimbra@redhat.com> Message-ID: <5652E52B.3010909@redhat.com> Hi Emily, the problem is Specialization is not defined per bean archive but per application. A bean is either specialized or not. Note that specialization is not tied to alternatives. WRT your use-case: the specializing bean should be enabled globally or in each bean archive which is using the specialized bean. Martin Dne 23.11.2015 v 10:54 Emily Jiang napsal(a): > Thank you Tom and Matej for your response! > The alternative was enabled in the archive beans-xml-modified.jar, but > it is not enabled in the archive beans-xml-modified2.jar. The issue is > not with alternative but with Specialized. > > At the moment, Weld specialized is effective even if itself is not > enabled, which is not desirable because it disables other bean but > itself is not enabled. As a consequence, this causes deployment error. > > The CDI 1.2 section 4.3 spec says: > 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. > > It is true the above sentence comments about an enabled bean. It hits an > disabled bean should not specialize a second bean. If you guys think it > is unclear, can we update the spec to clarify this scenario? > > By the way, OWB and Weld behave differently (Weld thinks a disabled bean > still specializes a second bean while OWB thinks a disabled bean does > NOT specialize a second bean). This is something we can leave to > implementation. We should spec it! > > On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny > wrote: > > Hello Emily > > I agree with Tom. In your case, specialized producer is enabled (via > beans.xml) although only per bean archive. > > > And about this: > >>From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. > > It is true, however the spec doesn't define how does a @Specialized > bean behave when it is disabled (or at least I haven't found that bit). > So this leaves it up to implementation and I can't really see a > problem with it. Why would you create a @Specialized bean and > disable it afterwards (with no other @Specialized and/or > @Alternative active)? > > > Matej > > ----- Original Message ----- > From: "Tomas Remes" > > To: "Emily Jiang" > > Cc: "cdi-dev" > > Sent: Monday, November 23, 2015 8:33:44 AM > Subject: Re: [cdi-dev] Clarification on 4.3 Specialization > > > Hi Emily, > > I am not sure I follow. What is disabled? > AlternativeCounterProducerModified? I can see > AlternativeCounterProducerModified is enabled in beans.xml of the > given bean archive and it means it is selected alternative only per > the bean archive. So I can't see any problem (or maybe I don't fully > understand). > > Tom > > ----- Original Message ----- > From: "Emily Jiang" > > To: "cdi-dev" > > Sent: Sunday, November 22, 2015 10:42:29 PM > Subject: Re: [cdi-dev] Clarification on 4.3 Specialization > > any thoughts? > > Should a bean with @Specialize disable a bean even if it is disabled > itself? > > On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang < > emijiang6 at googlemail.com > wrote: > > > > > 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 at CounterModifiedQualifier String modifiedProducer; > > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > > My application failed deployment with the error on Weld but worked > on OpenWebBeans > > [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) > -- > > > 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. > > > I also checked the spec: > @Alternative @Specializes > public class MockAsynchronousService extends AsynchronousService { > ... > } > 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. I > would like to know what other people think. > > > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > -- > Tomas Remes > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Software Engineer Red Hat, Czech Republic From emijiang6 at googlemail.com Mon Nov 23 05:30:54 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 23 Nov 2015 10:30:54 +0000 Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: <5652E52B.3010909@redhat.com> References: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> <735397814.15187222.1448268319886.JavaMail.zimbra@redhat.com> <5652E52B.3010909@redhat.com> Message-ID: Hi Martin, Although the spec does not enforce that @Specialized must be used in conjunction with @Alternative , I would like to unify the understanding of what the spec behavior of @Specialized on an disabled bean is. Thanks Emily On Mon, Nov 23, 2015 at 10:06 AM, Martin Kouba wrote: > Hi Emily, > > the problem is Specialization is not defined per bean archive but per > application. A bean is either specialized or not. Note that specialization > is not tied to alternatives. > > WRT your use-case: the specializing bean should be enabled globally or in > each bean archive which is using the specialized bean. > > Martin > > Dne 23.11.2015 v 10:54 Emily Jiang napsal(a): > >> Thank you Tom and Matej for your response! >> The alternative was enabled in the archive beans-xml-modified.jar, but >> it is not enabled in the archive beans-xml-modified2.jar. The issue is >> not with alternative but with Specialized. >> >> At the moment, Weld specialized is effective even if itself is not >> enabled, which is not desirable because it disables other bean but >> itself is not enabled. As a consequence, this causes deployment error. >> >> The CDI 1.2 section 4.3 spec says: >> 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. >> >> It is true the above sentence comments about an enabled bean. It hits an >> disabled bean should not specialize a second bean. If you guys think it >> is unclear, can we update the spec to clarify this scenario? >> >> By the way, OWB and Weld behave differently (Weld thinks a disabled bean >> still specializes a second bean while OWB thinks a disabled bean does >> NOT specialize a second bean). This is something we can leave to >> implementation. We should spec it! >> >> On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny > > wrote: >> >> Hello Emily >> >> I agree with Tom. In your case, specialized producer is enabled (via >> beans.xml) although only per bean archive. >> >> >> And about this: >> >>From Weld's perspective, any bean annotated with @Specialized >> disables a second bean regardless whether itself is active or not. >> >> It is true, however the spec doesn't define how does a @Specialized >> bean behave when it is disabled (or at least I haven't found that >> bit). >> So this leaves it up to implementation and I can't really see a >> problem with it. Why would you create a @Specialized bean and >> disable it afterwards (with no other @Specialized and/or >> @Alternative active)? >> >> >> Matej >> >> ----- Original Message ----- >> From: "Tomas Remes" > >> To: "Emily Jiang" > > >> Cc: "cdi-dev" > cdi-dev at lists.jboss.org>> >> Sent: Monday, November 23, 2015 8:33:44 AM >> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization >> >> >> Hi Emily, >> >> I am not sure I follow. What is disabled? >> AlternativeCounterProducerModified? I can see >> AlternativeCounterProducerModified is enabled in beans.xml of the >> given bean archive and it means it is selected alternative only per >> the bean archive. So I can't see any problem (or maybe I don't fully >> understand). >> >> Tom >> >> ----- Original Message ----- >> From: "Emily Jiang" > > >> To: "cdi-dev" > cdi-dev at lists.jboss.org>> >> Sent: Sunday, November 22, 2015 10:42:29 PM >> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization >> >> any thoughts? >> >> Should a bean with @Specialize disable a bean even if it is disabled >> itself? >> >> On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang < >> emijiang6 at googlemail.com > wrote: >> >> >> >> >> 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 at CounterModifiedQualifier String modifiedProducer; >> >> beans-xml-modified.jar.jar >> CounterModifiedQualifier (the interface) >> CounterProducerModified (the bean implementing that interface) >> AlternativeCounterProducerModified (an alternative specialized bean) >> beans.xml >> >> >> com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified >> >> >> My application failed deployment with the error on Weld but worked >> on OpenWebBeans >> >> [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) >> -- >> >> >> 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. >> >> >> I also checked the spec: >> @Alternative @Specializes >> public class MockAsynchronousService extends AsynchronousService { >> ... >> } >> 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. I >> would like to know what other people think. >> >> >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> -- >> Tomas Remes >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151123/4d363bad/attachment.html From manovotn at redhat.com Mon Nov 23 06:13:39 2015 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 23 Nov 2015 06:13:39 -0500 (EST) Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: References: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> <735397814.15187222.1448268319886.JavaMail.zimbra@redhat.com> <5652E52B.3010909@redhat.com> Message-ID: <1612472747.15367447.1448277219742.JavaMail.zimbra@redhat.com> Hi, Emily before we delve into questions regarding spec clarification, I have two questions for you :) 1) What is the point of disabling @Specialized bean(be it with @Veto or @Alternative) when you have no other @Specialized bean to take its place? - this use case just feels....weird at best? - to me it seems rather unusual, I guess you need to achieve different behavior in two cases - that's what you can do with 2 @Spec beans 2) Isn't there always a way around to achieve what you are aiming for? - enabling it app-wise with @Priority or using two @Specialized beans with additional qualifiers? - this way you are still moving within boundaries of current spec and can achieve the same goal - could you, please, give me a use-case where your scenario is absolutely necessary? Matej ----- Original Message ----- From: "Emily Jiang" To: "Martin Kouba" Cc: "Matej Novotny" , "cdi-dev" Sent: Monday, November 23, 2015 11:30:54 AM Subject: Re: [cdi-dev] Clarification on 4.3 Specialization Hi Martin, Although the spec does not enforce that @Specialized must be used in conjunction with @Alternative , I would like to unify the understanding of what the spec behavior of @Specialized on an disabled bean is. Thanks Emily On Mon, Nov 23, 2015 at 10:06 AM, Martin Kouba wrote: > Hi Emily, > > the problem is Specialization is not defined per bean archive but per > application. A bean is either specialized or not. Note that specialization > is not tied to alternatives. > > WRT your use-case: the specializing bean should be enabled globally or in > each bean archive which is using the specialized bean. > > Martin > > Dne 23.11.2015 v 10:54 Emily Jiang napsal(a): > >> Thank you Tom and Matej for your response! >> The alternative was enabled in the archive beans-xml-modified.jar, but >> it is not enabled in the archive beans-xml-modified2.jar. The issue is >> not with alternative but with Specialized. >> >> At the moment, Weld specialized is effective even if itself is not >> enabled, which is not desirable because it disables other bean but >> itself is not enabled. As a consequence, this causes deployment error. >> >> The CDI 1.2 section 4.3 spec says: >> 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. >> >> It is true the above sentence comments about an enabled bean. It hits an >> disabled bean should not specialize a second bean. If you guys think it >> is unclear, can we update the spec to clarify this scenario? >> >> By the way, OWB and Weld behave differently (Weld thinks a disabled bean >> still specializes a second bean while OWB thinks a disabled bean does >> NOT specialize a second bean). This is something we can leave to >> implementation. We should spec it! >> >> On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny > > wrote: >> >> Hello Emily >> >> I agree with Tom. In your case, specialized producer is enabled (via >> beans.xml) although only per bean archive. >> >> >> And about this: >> >>From Weld's perspective, any bean annotated with @Specialized >> disables a second bean regardless whether itself is active or not. >> >> It is true, however the spec doesn't define how does a @Specialized >> bean behave when it is disabled (or at least I haven't found that >> bit). >> So this leaves it up to implementation and I can't really see a >> problem with it. Why would you create a @Specialized bean and >> disable it afterwards (with no other @Specialized and/or >> @Alternative active)? >> >> >> Matej >> >> ----- Original Message ----- >> From: "Tomas Remes" > >> To: "Emily Jiang" > > >> Cc: "cdi-dev" > cdi-dev at lists.jboss.org>> >> Sent: Monday, November 23, 2015 8:33:44 AM >> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization >> >> >> Hi Emily, >> >> I am not sure I follow. What is disabled? >> AlternativeCounterProducerModified? I can see >> AlternativeCounterProducerModified is enabled in beans.xml of the >> given bean archive and it means it is selected alternative only per >> the bean archive. So I can't see any problem (or maybe I don't fully >> understand). >> >> Tom >> >> ----- Original Message ----- >> From: "Emily Jiang" > > >> To: "cdi-dev" > cdi-dev at lists.jboss.org>> >> Sent: Sunday, November 22, 2015 10:42:29 PM >> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization >> >> any thoughts? >> >> Should a bean with @Specialize disable a bean even if it is disabled >> itself? >> >> On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang < >> emijiang6 at googlemail.com > wrote: >> >> >> >> >> 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 at CounterModifiedQualifier String modifiedProducer; >> >> beans-xml-modified.jar.jar >> CounterModifiedQualifier (the interface) >> CounterProducerModified (the bean implementing that interface) >> AlternativeCounterProducerModified (an alternative specialized bean) >> beans.xml >> >> >> com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified >> >> >> My application failed deployment with the error on Weld but worked >> on OpenWebBeans >> >> [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) >> -- >> >> >> 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. >> >> >> I also checked the spec: >> @Alternative @Specializes >> public class MockAsynchronousService extends AsynchronousService { >> ... >> } >> 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. I >> would like to know what other people think. >> >> >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> -- >> Tomas Remes >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 ( >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other >> intellectual property rights inherent in such information. >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Thanks Emily ================= Emily Jiang ejiang at apache.org From emijiang6 at googlemail.com Mon Nov 23 06:33:21 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 23 Nov 2015 11:33:21 +0000 Subject: [cdi-dev] Clarification on 4.3 Specialization In-Reply-To: <1612472747.15367447.1448277219742.JavaMail.zimbra@redhat.com> References: <137547694.21851250.1448264024355.JavaMail.zimbra@redhat.com> <735397814.15187222.1448268319886.JavaMail.zimbra@redhat.com> <5652E52B.3010909@redhat.com> <1612472747.15367447.1448277219742.JavaMail.zimbra@redhat.com> Message-ID: This is a test application and test this spec section 4.3. I would like to see the application behaves the same on both Weld and OWB. On Mon, Nov 23, 2015 at 11:13 AM, Matej Novotny wrote: > Hi, Emily > > before we delve into questions regarding spec clarification, I have two > questions for you :) > > 1) What is the point of disabling @Specialized bean(be it with @Veto or > @Alternative) when you have no other @Specialized bean to take its place? > - this use case just feels....weird at best? > - to me it seems rather unusual, I guess you need to achieve different > behavior in two cases - that's what you can do with 2 @Spec beans > > 2) Isn't there always a way around to achieve what you are aiming for? > - enabling it app-wise with @Priority or using two @Specialized beans > with additional qualifiers? > - this way you are still moving within boundaries of current spec and can > achieve the same goal > - could you, please, give me a use-case where your scenario is absolutely > necessary? > > Matej > > ----- Original Message ----- > From: "Emily Jiang" > To: "Martin Kouba" > Cc: "Matej Novotny" , "cdi-dev" < > cdi-dev at lists.jboss.org> > Sent: Monday, November 23, 2015 11:30:54 AM > Subject: Re: [cdi-dev] Clarification on 4.3 Specialization > > Hi Martin, > Although the spec does not enforce that @Specialized must be used in > conjunction with @Alternative , I would like to unify the understanding of > what the spec behavior of @Specialized on an disabled bean is. > > Thanks > Emily > > On Mon, Nov 23, 2015 at 10:06 AM, Martin Kouba wrote: > > > Hi Emily, > > > > the problem is Specialization is not defined per bean archive but per > > application. A bean is either specialized or not. Note that > specialization > > is not tied to alternatives. > > > > WRT your use-case: the specializing bean should be enabled globally or in > > each bean archive which is using the specialized bean. > > > > Martin > > > > Dne 23.11.2015 v 10:54 Emily Jiang napsal(a): > > > >> Thank you Tom and Matej for your response! > >> The alternative was enabled in the archive beans-xml-modified.jar, but > >> it is not enabled in the archive beans-xml-modified2.jar. The issue is > >> not with alternative but with Specialized. > >> > >> At the moment, Weld specialized is effective even if itself is not > >> enabled, which is not desirable because it disables other bean but > >> itself is not enabled. As a consequence, this causes deployment error. > >> > >> The CDI 1.2 section 4.3 spec says: > >> 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. > >> > >> It is true the above sentence comments about an enabled bean. It hits an > >> disabled bean should not specialize a second bean. If you guys think it > >> is unclear, can we update the spec to clarify this scenario? > >> > >> By the way, OWB and Weld behave differently (Weld thinks a disabled bean > >> still specializes a second bean while OWB thinks a disabled bean does > >> NOT specialize a second bean). This is something we can leave to > >> implementation. We should spec it! > >> > >> On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny >> > wrote: > >> > >> Hello Emily > >> > >> I agree with Tom. In your case, specialized producer is enabled (via > >> beans.xml) although only per bean archive. > >> > >> > >> And about this: > >> >>From Weld's perspective, any bean annotated with @Specialized > >> disables a second bean regardless whether itself is active or not. > >> > >> It is true, however the spec doesn't define how does a @Specialized > >> bean behave when it is disabled (or at least I haven't found that > >> bit). > >> So this leaves it up to implementation and I can't really see a > >> problem with it. Why would you create a @Specialized bean and > >> disable it afterwards (with no other @Specialized and/or > >> @Alternative active)? > >> > >> > >> Matej > >> > >> ----- Original Message ----- > >> From: "Tomas Remes" > > >> To: "Emily Jiang" >> > > >> Cc: "cdi-dev" >> cdi-dev at lists.jboss.org>> > >> Sent: Monday, November 23, 2015 8:33:44 AM > >> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization > >> > >> > >> Hi Emily, > >> > >> I am not sure I follow. What is disabled? > >> AlternativeCounterProducerModified? I can see > >> AlternativeCounterProducerModified is enabled in beans.xml of the > >> given bean archive and it means it is selected alternative only per > >> the bean archive. So I can't see any problem (or maybe I don't fully > >> understand). > >> > >> Tom > >> > >> ----- Original Message ----- > >> From: "Emily Jiang" >> > > >> To: "cdi-dev" >> cdi-dev at lists.jboss.org>> > >> Sent: Sunday, November 22, 2015 10:42:29 PM > >> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization > >> > >> any thoughts? > >> > >> Should a bean with @Specialize disable a bean even if it is disabled > >> itself? > >> > >> On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang < > >> emijiang6 at googlemail.com > wrote: > >> > >> > >> > >> > >> 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 at CounterModifiedQualifier String modifiedProducer; > >> > >> beans-xml-modified.jar.jar > >> CounterModifiedQualifier (the interface) > >> CounterProducerModified (the bean implementing that interface) > >> AlternativeCounterProducerModified (an alternative specialized bean) > >> beans.xml > >> > >> > >> > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > >> > >> > >> My application failed deployment with the error on Weld but worked > >> on OpenWebBeans > >> > >> [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) > >> -- > >> > >> > >> 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. > >> > >> > >> I also checked the spec: > >> @Alternative @Specializes > >> public class MockAsynchronousService extends AsynchronousService { > >> ... > >> } > >> 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. I > >> would like to know what other people think. > >> > >> > >> Thanks > >> Emily > >> ================= > >> Emily Jiang > >> ejiang at apache.org > >> > >> > >> > >> -- > >> Thanks > >> Emily > >> ================= > >> Emily Jiang > >> ejiang at apache.org > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > >> > >> -- > >> Tomas Remes > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses > >> the code under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > >> ideas provided on this list, the provider waives all patent and > >> other intellectual property rights inherent in such information. > >> > >> > >> > >> > >> -- > >> Thanks > >> Emily > >> ================= > >> Emily Jiang > >> ejiang at apache.org > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > >> code under the Apache License, Version 2 ( > >> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other > >> intellectual property rights inherent in such information. > >> > >> > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151123/22df8fd6/attachment-0001.html From issues at jboss.org Mon Nov 23 11:29:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 23 Nov 2015 11:29:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132814#comment-13132814 ] Antoine Sabot-Durand commented on CDI-558: ------------------------------------------ Here's the table: ||Builder||Access|| |{{AnnotatedTypeBuilder}}|Should be accessible everywhere (even from outside CDI). We should avoid adding it as a class and find a way to easily get an instance from the implementation| |{{BeanAttributesBuilder}}|{{ProcessBeanAttributes}}| |{{InjectionPointBuilder}}|{{ProcessInjectionPoint}}| |{{ObserverMethodBuilder}}|{{ProcessObserverMethod}},{{AfterBeandiscovery}}| |{{BeanBuilder}}|{{AfterBeanDiscovery}}| > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 24 02:23:00 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 24 Nov 2015 02:23:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132980#comment-13132980 ] Tomas Remes commented on CDI-558: --------------------------------- Wrt {{AnnotatedTypeBuilder}} what do you mean by "from outside CDI"? What about to introduce {{AnnotatedTypeBuilder}} as a built-in bean? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 24 03:31:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 24 Nov 2015 03:31:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132991#comment-13132991 ] Antoine Sabot-Durand commented on CDI-558: ------------------------------------------ One use case would be : in Java SE I want to prepare an AnnotatedType to give it as on of the type to discover during container initialization. That's why it can be useful to have a way to create such an AnnotatedType before the container and BeanManager availability. So the built-in bean is not a good idea IMO. If we agree on that I see several solution #. Put the class in the spec (I don't like it unless we don't find a better solution) #. Use Java service loader like we already do with CDIProvider. The loaded service should be a factory allowing getting an instance for AnnotatedTypeBuilder (yeah a factory of builder). That let us the possibility to add another helpers in it later. #. Same as previous but with a classical implementation lookup in classpath. The difference is that service loader is guarantee to still work with java 9 Any other thoughts ? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 24 03:31:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 24 Nov 2015 03:31:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132991#comment-13132991 ] Antoine Sabot-Durand edited comment on CDI-558 at 11/24/15 3:30 AM: -------------------------------------------------------------------- One use case would be : in Java SE I want to prepare an AnnotatedType to give it as on of the type to discover during container initialization. That's why it can be useful to have a way to create such an AnnotatedType before the container and BeanManager availability. So the built-in bean is not a good idea IMO. If we agree on that I see several solution # Put the class in the spec (I don't like it unless we don't find a better solution) # Use Java service loader like we already do with CDIProvider. The loaded service should be a factory allowing getting an instance for AnnotatedTypeBuilder (yeah a factory of builder). That let us the possibility to add another helpers in it later. # Same as previous but with a classical implementation lookup in classpath. The difference is that service loader is guarantee to still work with java 9 Any other thoughts ? was (Author: antoinesabot-durand): One use case would be : in Java SE I want to prepare an AnnotatedType to give it as on of the type to discover during container initialization. That's why it can be useful to have a way to create such an AnnotatedType before the container and BeanManager availability. So the built-in bean is not a good idea IMO. If we agree on that I see several solution #. Put the class in the spec (I don't like it unless we don't find a better solution) #. Use Java service loader like we already do with CDIProvider. The loaded service should be a factory allowing getting an instance for AnnotatedTypeBuilder (yeah a factory of builder). That let us the possibility to add another helpers in it later. #. Same as previous but with a classical implementation lookup in classpath. The difference is that service loader is guarantee to still work with java 9 Any other thoughts ? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Nov 24 05:27:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 24 Nov 2015 05:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-573: ---------------------------------------- Summary: Review code of CDI class to switch to ServiceLoader Key: CDI-573 URL: https://issues.jboss.org/browse/CDI-573 Project: CDI Specification Issues Issue Type: Feature Request Components: Concepts Affects Versions: 2.0-EDR1 Reporter: Antoine Sabot-Durand Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Tue Nov 24 05:41:17 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 24 Nov 2015 10:41:17 +0000 Subject: [cdi-dev] Today's meeting agenda Message-ID: Hi guys, In todays meeting, We should discuss CDI-10 & related issues. I also like to discuss metadata builder (CDI-558) and give you some insight regarding CDI light. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151124/13483017/attachment.html From issues at jboss.org Tue Nov 24 10:24:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Tue, 24 Nov 2015 10:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: Emily Jiang created CDI-574: ------------------------------- Summary: 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 at CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified My application failed deployment with the error on Weld but worked on OpenWebBeans [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) -- 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) From emijiang6 at googlemail.com Tue Nov 24 10:27:05 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Tue, 24 Nov 2015 15:27:05 +0000 Subject: [cdi-dev] Today's meeting agenda In-Reply-To: References: Message-ID: Hi Antoine, Is it possible to discuss this CDI jira ( https://issues.jboss.org/projects/CDI/issues/CDI-574)? Thanks Emily On Tue, Nov 24, 2015 at 10:41 AM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Hi guys, > > In todays meeting, We should discuss CDI-10 & related issues. I also like > to discuss metadata builder (CDI-558) and give you some insight regarding > CDI light. > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151124/ce72721a/attachment-0001.html From issues at jboss.org Tue Nov 24 10:35:02 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 24 Nov 2015 10:35:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133338#comment-13133338 ] Martin Kouba commented on CDI-574: ---------------------------------- bq. From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. Not exactly. From Weld's perspective a *specializing* bean enabled in any bean archive disables any *specialized* bean in the application. Note that specialization is not defined per bean archive... > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > My application failed deployment with the error on Weld but worked on OpenWebBeans > [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) > -- > 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) From issues at jboss.org Tue Nov 24 11:36:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 24 Nov 2015 11:36:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-574: ------------------------------------- Description: 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 at CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified 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. was: 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 at CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified My application failed deployment with the error on Weld but worked on OpenWebBeans [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) -- 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. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Tue Nov 24 11:40:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 24 Nov 2015 11:40:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133410#comment-13133410 ] Antoine Sabot-Durand commented on CDI-574: ------------------------------------------ Sorry Emily. I understand roughly your question, but could you detail your use case. You're talking about producer, there is not code for them. I don't understand where the CounterProducerConsumerModified2 bean is defined. >From here it looks like a corner case, but I may be wrong. Could you format your code and add your whole example. Thx. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From emijiang6 at googlemail.com Tue Nov 24 12:07:50 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Tue, 24 Nov 2015 17:07:50 +0000 Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: Here is the file On Tue, Nov 24, 2015 at 4:40 PM, Antoine Sabot-Durand (JIRA) < issues at jboss.org> wrote: > > [ > https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133410#comment-13133410 > ] > > Antoine Sabot-Durand commented on CDI-574: > ------------------------------------------ > > Sorry Emily. I understand roughly your question, but could you detail your > use case. You're talking about producer, there is not code for them. I > don't understand where the CounterProducerConsumerModified2 bean is defined. > From here it looks like a corner case, but I may be wrong. Could you > format your code and add your whole example. Thx. > > > 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 at CounterModifiedQualifier String modifiedProducer; > > beans-xml-modified.jar.jar > > CounterModifiedQualifier (the interface) > > CounterProducerModified (the bean implementing that interface) > > AlternativeCounterProducerModified (an alternative specialized bean) > > beans.xml > > > > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > > > 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) > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151124/f1bdf820/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: testDiffBDA.war Type: application/octet-stream Size: 7618 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20151124/f1bdf820/attachment-0001.obj From issues at jboss.org Wed Nov 25 03:05:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 25 Nov 2015 03:05:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133587#comment-13133587 ] Mark Struberg commented on CDI-574: ----------------------------------- The spec pretty imo clearly states that *only* _enabled_ specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled (because it is not an enabled alternative) then it does not disable the original bean. There is not even a 'non porbable behaviour results' section for it. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Wed Nov 25 03:10:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 25 Nov 2015 03:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133589#comment-13133589 ] Martin Kouba commented on CDI-574: ---------------------------------- bq. The spec pretty imo clearly states that only enabled specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled... In this particular use-case the specialized bean is enabled in one bean archive and disabled in the second bean archive. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Wed Nov 25 09:44:00 2015 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Wed, 25 Nov 2015 09:44:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133817#comment-13133817 ] Emily Jiang commented on CDI-574: --------------------------------- This was discussed in Yesterday's cdi-dev chat: http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23cdi-dev.2015-11-24.log.html The conclusion from Antoine: Weld complies with spec but OWB does not, even though the spec is not user friendly. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Wed Nov 25 11:12:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 25 Nov 2015 11:12:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133875#comment-13133875 ] Mark Struberg commented on CDI-574: ----------------------------------- No, this is imo an inconsistency in Weld. It is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option). See CDI-18 and other issues for the discussion. In OWB the alternative is 'per ee module' by default. So the whole EE module (e.g. a single WAR) either has the alternative enabled or not. And thus the whole specialized bean is enabled for the whole ee module or not. That way we are a.) much faster (as we don't need to check the invoker chain each proxy invocation) and b.) more consistent. EE-modules usually are 1:1 to ClassLoaders and BeanManagers. Thus for each BeanManager a bean is clearly either enabled or not. It's an old story that the bda-per-jar interpretation is inconsistent within itself. How should that be solved? Will the observer method in the specialized away bean get invoked or not? What if I just add a SINGLE jar which don't have this Alternative enabled? Will the observer method then get invoked again? What about implicit bean archives? Those are almost always present, Just add a single slf4j api or whatever other util jar. In practice this will render disabling beans via specialisation useless. etc, . > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Wed Nov 25 11:19:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 25 Nov 2015 11:19:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133875#comment-13133875 ] Mark Struberg edited comment on CDI-574 at 11/25/15 11:18 AM: -------------------------------------------------------------- Imo OWB is spec conform as well. It's all a matter of how you interpret the term BDA in the CDI spec. The inconsistency in Weld is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option). See CDI-18 and other issues for the discussion. In OWB the alternative is 'per ee module' by default. So the whole EE module (e.g. a single WAR) either has the alternative enabled or not. And thus the whole specialized bean is enabled for the whole ee module or not. That way we are a.) much faster (as we don't need to check the invoker chain each proxy invocation) and b.) more consistent. EE-modules usually are 1:1 to ClassLoaders and BeanManagers. Thus for each BeanManager a bean is clearly either enabled or not. It's an old story that the bda-per-jar interpretation is inconsistent within itself. How should that be solved? Will the observer method in the specialized away bean get invoked or not? What if I just add a SINGLE jar which don't have this Alternative enabled? Will the observer method then get invoked again? What about implicit bean archives? Those are almost always present, Just add a single slf4j api or whatever other util jar. In practice this will render disabling beans via specialisation useless. etc, . was (Author: struberg): No, this is imo an inconsistency in Weld. It is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option). See CDI-18 and other issues for the discussion. In OWB the alternative is 'per ee module' by default. So the whole EE module (e.g. a single WAR) either has the alternative enabled or not. And thus the whole specialized bean is enabled for the whole ee module or not. That way we are a.) much faster (as we don't need to check the invoker chain each proxy invocation) and b.) more consistent. EE-modules usually are 1:1 to ClassLoaders and BeanManagers. Thus for each BeanManager a bean is clearly either enabled or not. It's an old story that the bda-per-jar interpretation is inconsistent within itself. How should that be solved? Will the observer method in the specialized away bean get invoked or not? What if I just add a SINGLE jar which don't have this Alternative enabled? Will the observer method then get invoked again? What about implicit bean archives? Those are almost always present, Just add a single slf4j api or whatever other util jar. In practice this will render disabling beans via specialisation useless. etc, . > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 03:33:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 26 Nov 2015 03:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134043#comment-13134043 ] Martin Kouba commented on CDI-574: ---------------------------------- bq. The inconsistency in Weld is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option) Well, I would call it a spec inconsistency. One might argue that a jar inside WEB-INF/lib is a library and the spec states _"The Java EE module or library is a bean archive..."_. Also the spec *does not say anything about beans.xml merging* which is required if OWB interpretation is used. E.g. what happens if there are two libs inside WEB-INF/lib. One enables an alternative and the second does not and expects it to be disabled? It's a complicated topic. However, I think it's NOT fair to mark Weld interpretation as inconsistent if the correct behaviour is disputable. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 04:16:10 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 26 Nov 2015 04:16:10 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134058#comment-13134058 ] Mark Struberg commented on CDI-574: ----------------------------------- I agree that the spec is not perfectly accurate. And yes, OWB solves this black spot by merging beans.xml files internally. I am working with big CDI projects since 6 years and I _never_ had the urge to have a bean enabled in one jar and disabled in another. Nor does any of the 5k++ conference listeners I asked in the many talks I gave around the globe. Actually the per-jar enablement of alternatives and interceptors is the No1 most-hated behaviour of CDI ;) Anyway, lets get back to the original question with @Alternative @Specializes (which is also a prominent example in the spec since CDI-1.0) and 2 jars where in 1 the alternative is enabled and in the other it isn't. What is the expected outcome? > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 04:42:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 26 Nov 2015 04:42:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134074#comment-13134074 ] Martin Kouba commented on CDI-574: ---------------------------------- bq. What is the expected outcome? The specializing bean is enabled in one bean archive and disabled in the second bean archive. And you will probably get unsatisfied dependency because the specialized bean is completely ignored. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 04:43:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 26 Nov 2015 04:43:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133589#comment-13133589 ] Martin Kouba edited comment on CDI-574 at 11/26/15 4:42 AM: ------------------------------------------------------------ bq. The spec pretty imo clearly states that only enabled specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled... In this particular use-case the specializing bean is enabled in one bean archive and disabled in the second bean archive. was (Author: mkouba): bq. The spec pretty imo clearly states that only enabled specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled... In this particular use-case the specialized bean is enabled in one bean archive and disabled in the second bean archive. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 05:09:00 2015 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 26 Nov 2015 05:09:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134143#comment-13134143 ] Matej Novotny commented on CDI-574: ----------------------------------- bq. The specializing bean is enabled in one bean archive and disabled in the second bean archive. And you will probably get unsatisfied dependency because the specialized bean is completely ignored. +1, I agree with Martin. As clumsy as it may sounds at first, it makes sense. Soon as you enable specializing bean in one archive it disables the original bean. So much for specialization, it is not limited to archives. Then there is @Alternative - enabling it (talking about different archive as per example given) will allow the @Specialized bean to work, not having it enabled will attempt to use the original bean which is disabled hence resulting in an error (unsatisfied dep. in this case). > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 05:12:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 26 Nov 2015 05:12:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134146#comment-13134146 ] Mark Struberg commented on CDI-574: ----------------------------------- You both ignored my question: what happens with an observer in there? How to disable them effectively? In Weld it is simply not possible it seems. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 05:14:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 26 Nov 2015 05:14:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134149#comment-13134149 ] Mark Struberg commented on CDI-574: ----------------------------------- .bq Soon as you enable specializing bean in one archive it disables the original bean. That means your app will not even start? And even if, there is no way it could run because in the other jar it would permanently blow up with BeanNotFound or whatever... > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 06:18:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 26 Nov 2015 06:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134198#comment-13134198 ] Martin Kouba commented on CDI-574: ---------------------------------- bq. what happens with an observer in there? Sorry, I'm not sure I understand your question. However, if there is an observer declared on the specialized bean, then this observer is ignored. See also 4.3. Specialization: _"Even if the second bean defines a producer or observer method, the method will never be called."_ > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Thu Nov 26 11:20:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 26 Nov 2015 11:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134422#comment-13134422 ] Mark Struberg commented on CDI-574: ----------------------------------- But your quote is only true for an 'enabled' specialization. Means if they have @alternative but are never activated then it is disabled. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Mon Nov 30 02:40:00 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 30 Nov 2015 02:40:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134919#comment-13134919 ] Martin Kouba commented on CDI-574: ---------------------------------- No, it's not. The current wording of the spec does not define specialization on the bean archive level. It only states that if an enabled bean specializes a second bean, the second bean is never instantiated. Anyway, it seems it does not makes sense to continue on this discussion as we can't agree on this. It's up to the spec lead. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Mon Nov 30 03:08:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 30 Nov 2015 03:08:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134932#comment-13134932 ] Mark Struberg commented on CDI-574: ----------------------------------- But all those rules explicitly ONLY apply for specialization by ENABLED beans as defined in 5.1.2. According to the spec the observer method in the base class must get used if there are only non-enabled @Alternatives. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Mon Nov 30 03:37:02 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 30 Nov 2015 03:37:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134949#comment-13134949 ] Antoine Sabot-Durand commented on CDI-574: ------------------------------------------ Guys. I already gave my opinion during last meeting: * alternatives can be selected at bean archive level * specialization is global * If an alternative is selected in at least one bean archive the bean is enabled. * If a specializes bean is enabled, the bean that was specialized is disabled There is no ambiguity here. I agree that it's not an intuitive behavior but now it's written in black on white in the spec. On the other hand I find the topic very "corner-case-ish" : the use case described suppose that I own the corresponding bean archive so I can change their config (or use {{@Priority}}) to obtain the expected behavior. Working on a global config proposal (as we spoke during face to face) would more helpful than continuing this thread IMO. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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) From issues at jboss.org Mon Nov 30 05:24:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 30 Nov 2015 05:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-563: ------------------------------------- Fix Version/s: 2.0-EDR2 > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Fix For: 2.0-EDR2 > > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 30 05:24:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 30 Nov 2015 05:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-563: ---------------------------------------- Assignee: Antoine Sabot-Durand > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 30 05:27:00 2015 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 30 Nov 2015 05:27:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-563 started by Antoine Sabot-Durand. ------------------------------------------------ > Event.fireAsync() - clarify the usage of the returned CompletionStage > --------------------------------------------------------------------- > > Key: CDI-563 > URL: https://issues.jboss.org/browse/CDI-563 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: > {quote} > * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. > {quote} > So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: > {code:java} > event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); > {code} > And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Nov 30 14:52:00 2015 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 30 Nov 2015 14:52:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135310#comment-13135310 ] Mark Struberg commented on CDI-574: ----------------------------------- I fear there pretty much _is_ ambiguity with this interpretation. Because in all the other bean archives - where the @Alternative @Specializes is *not* active there is NO bean satisfying these types at all! Because for *them* the original bean is disabled because it is 'specialized away' but the @Alternative @Specializes bean is not enabled neither... This app imo shouldn't even start. Because if it does then it will blow up at runtime. > 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 at CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > > com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified > > 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)