From issues at jboss.org Thu Sep 1 02:54:01 2016 From: issues at jboss.org (Michael Kotten (JIRA)) Date: Thu, 1 Sep 2016 02:54:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-415) Observer resolution doesn't specify handling of null parameter values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287112#comment-13287112 ] Michael Kotten commented on CDI-415: ------------------------------------ It should be explicitly stated that _null_ is a non valid value for an event. In the end this might be, because you can't extract the type of _null_. BTW, OWB just crashes with a NPE when calling getClass() ;-). > Observer resolution doesn't specify handling of null parameter values > --------------------------------------------------------------------- > > Key: CDI-415 > URL: https://issues.jboss.org/browse/CDI-415 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Michael Kotten > Priority: Minor > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > There is a gap in chapter 10.2 of the current CDI spec about [observer resolution|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution]. It doesn't specify what should happen if an event gets fired using a null value. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 04:30:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Sep 2016 04:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-626: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 04:30:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Sep 2016 04:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-625: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 04:31:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Sep 2016 04:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-624: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: 2.0 (proposed)) > Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle > -------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-624 > URL: https://issues.jboss.org/browse/CDI-624 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > I believe we should not break the application initialization lifecycle. > So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean)}}. > The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 05:23:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Sep 2016 05:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-623: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 05:33:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 5 Sep 2016 05:33:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-437: ----------------------------- Labels: F2F2016 (was: ) > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 05:55:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 5 Sep 2016 05:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-437: ----------------------------- Priority: Minor (was: Major) > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 08:22:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Sep 2016 08:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-233) Specify target bean archive for bean added via AfterBeanDiscovery.addBean() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-233: ------------------------------------- Priority: Minor (was: Major) > Specify target bean archive for bean added via AfterBeanDiscovery.addBean() > --------------------------------------------------------------------------- > > Key: CDI-233 > URL: https://issues.jboss.org/browse/CDI-233 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016, visibility > Fix For: 2.0 (discussion) > > > This may have impact, provided that alternatives, interceptors or decorators are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 08:32:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 5 Sep 2016 08:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in Instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-232: ----------------------------- Priority: Minor (was: Major) > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance and Provider for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 09:43:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 5 Sep 2016 09:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-78. ----------------------------------- Resolution: Won't Fix Spec doesn't allow this anymore. And it's way too complicated from user perspective. > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 04:49:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 04:49:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288971#comment-13288971 ] Antoine Sabot-Durand commented on CDI-527: ------------------------------------------ In F2F meeting we decided to add "ignoreFinalMethod" method. Adding support for @WithAnnotations on the ProcessBeanAttributes (CDI-270) will also help to create team specific annotation allow this. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 05:07:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 05:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-599. ------------------------------------ Resolution: Rejected too complex to solve one use case. Feature will be done in CDi-527 > New lifecycle event to handle deployment/statup errors > ------------------------------------------------------ > > Key: CDI-599 > URL: https://issues.jboss.org/browse/CDI-599 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Mark Paluch > > With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. > For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application. > An example API could look like: > {code} > /** > * The container fires an event of this type for each deployment validation problem. Unhandled validation problems lead to a > * startup exception. Deployment validations can be handled so the container startup is no longer prevented by handled problems. > */ > public interface ProcessDeploymentValidation { > } > /** > * The container fires an event of this type in case of multiple beans match a certain combination of required type and required > * qualifiers and are eligible for injection. This problem can be handled by resolving a bean using {@link #resolve(Bean)}. > */ > public interface ProcessAmbiguousResolution extends ProcessDeploymentValidation { > /** > * > * @return the affected InjectionPoint. > */ > InjectionPoint getInjectionPoint(); > /** > * > * @return the set of matching beans for the InjectionPoint. > */ > Set> getMatchingBeans(); > /** > * Clarify bean resolution by specifying the bean to inject. > * > * @param bean > */ > void resolve(Bean bean); > } > /** > * The container fires an event of this type in case no bean matches a certain combination of required type and required > * qualifiers and is eligible for injection. This problem can be handled by providing a bean using {@link #resolve(Bean)}. > */ > public interface ProcessUnsatisfiedResolution extends ProcessDeploymentValidation { > /** > * > * @return the affected InjectionPoint. > */ > InjectionPoint getInjectionPoint(); > /** > * Clarify bean resolution by specifying the bean to inject. > * > * @param bean > */ > void resolve(Bean bean); > } > /** > * The container fires an event of this type in case a contextual reference for a bean with a normal scope and a certain bean > * type cannot be obtained because the bean type cannot be proxied by the container. > */ > public interface ProcessUnproxyableResolution extends ProcessDeploymentValidation { > /** > * The unproxyable bean. > * > * @return > */ > Bean getBean(); > /** > * Suppres this problem and allow bean instances that are partially unproxied. > */ > void allowUnproxyable(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 09:34:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 09:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-616) Injection point declared as transient is not useful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289260#comment-13289260 ] Antoine Sabot-Durand commented on CDI-616: ------------------------------------------ Vote on ML bring this resolution: Do nothing but add clarification in the spec : Injection in transient field is not supported. > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 09:39:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 09:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-616) Injection point declared as transient is not useful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289260#comment-13289260 ] Antoine Sabot-Durand edited comment on CDI-616 at 9/6/16 9:38 AM: ------------------------------------------------------------------ Vote on ML bring this resolution: Do nothing but add clarification in the spec : Injection in transient field is not supported. Section to add this is 5.2.3 and change the title to Legal Injection points. Mention should state "non portable behaviour will occur" was (Author: antoinesabot-durand): Vote on ML bring this resolution: Do nothing but add clarification in the spec : Injection in transient field is not supported. > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 (proposed) > > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 09:39:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 09:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-616) Injection point declared as transient is not useful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-616: ------------------------------------- Fix Version/s: 2.0 (proposed) > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 (proposed) > > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 10:47:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 10:47:01 -0400 (EDT) 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=13289344#comment-13289344 ] Antoine Sabot-Durand commented on CDI-10: ----------------------------------------- During F2F meeting 2016, we discussed addition of methods to Beabmanager retrieve the Bean, Contextual instance and original class for a given instance. Solution should be retrieving the Bean from an instance. Bean provides class, and allows context lookup to retrieve the contextual instance. > 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 Tue Sep 6 11:02:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 11:02:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289353#comment-13289353 ] Antoine Sabot-Durand commented on CDI-593: ------------------------------------------ We should mention this interface in the spec, and tell users that a custom bean being an alternative can implement it to be activated globaly. ObserverMethod section in the spec should be fixed. > Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc > ------------------------------------------------------------------------------------ > > Key: CDI-593 > URL: https://issues.jboss.org/browse/CDI-593 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * javadoc would definitely deserve some more info > * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 11:21:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 11:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-513: ------------------------------------- Priority: Minor (was: Major) > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Priority: Minor > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 11:57:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 11:57:00 -0400 (EDT) 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:all-tabpanel ] Antoine Sabot-Durand updated CDI-224: ------------------------------------- Fix Version/s: 2.0 (discussion) > 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 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 12:00:04 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 12:00:04 -0400 (EDT) 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=13289398#comment-13289398 ] Antoine Sabot-Durand commented on CDI-224: ------------------------------------------ To support this, we'd have to introduce a new kind of Decorators by enhancing @Decorator annotation (@Decorator(noView=true)) or a new annotation @NoViewDecorator > 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 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 12:00:04 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 6 Sep 2016 12:00:04 -0400 (EDT) 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:all-tabpanel ] Antoine Sabot-Durand reopened CDI-224: -------------------------------------- Assignee: Antoine Sabot-Durand (was: Pete Muir) > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Wed Sep 7 04:22:44 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 07 Sep 2016 08:22:44 +0000 Subject: [cdi-dev] Proposal for CDI-580 (intercepors for producers and custom beans) Message-ID: Hi all, Please review this proposal we made during F2F meeting regarding CDI-580: https://github.com/cdi-spec/cdi/tree/CDI-580 New spi interface is: https://github.com/antoinesd/cdi-spec/blob/c68730d294e614eee127288d7daa897e51db34bf/api/src/main/java/javax/enterprise/inject/spi/InterceptionProxyFactory.java usage is here: https://github.com/antoinesd/cdi-spec/tree/c68730d294e614eee127288d7daa897e51db34bf/api/src/test/java/org/jboss/cdi/api/test/interceptortricks Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160907/3e0f4189/attachment.html From builds at travis-ci.org Wed Sep 7 04:35:45 2016 From: builds at travis-ci.org (Travis CI) Date: Wed, 07 Sep 2016 08:35:45 +0000 Subject: [cdi-dev] Errored: cdi-spec/cdi#50 (CDI-580 - c68730d) In-Reply-To: Message-ID: <57cfd176377d6_33fb3a05966489440f4@344d99c5-5038-4634-8ef6-52d2236be5ad.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #50 Status: Errored Duration: 12 minutes and 16 seconds Commit: c68730d (CDI-580) Author: Antoine Sabot-Durand Message: Proposal for CDI-580 : Allow interceptors and decorators to be applied to the return value of a producer method Also works for custom beans create() View the changeset: https://github.com/cdi-spec/cdi/compare/07924c8c3c05^...c68730d294e6 View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/158104217 -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160907/272d4d8f/attachment-0001.html From issues at jboss.org Wed Sep 7 05:50:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 05:50:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289747#comment-13289747 ] Antoine Sabot-Durand commented on CDI-420: ------------------------------------------ During CDI F2F we proposed to provide this feature by adding configuration to the {{"all"}} mode with the {{}} xml element {code:xml} {code} > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 05:51:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 05:51:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-420: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 05:51:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 05:51:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-420: ------------------------------------- Labels: F2F2016 (was: ) > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 05:54:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 05:54:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-527: ------------------------------------- Labels: F2F2016 (was: ) > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 05:55:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 05:55:01 -0400 (EDT) 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:all-tabpanel ] Antoine Sabot-Durand updated CDI-224: ------------------------------------- Labels: F2F2016 (was: ) > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:01:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 06:01:01 -0400 (EDT) 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: ------------------------------------ Labels: F2F2016 (was: ) > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:02:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 06:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289759#comment-13289759 ] Antoine Sabot-Durand commented on CDI-471: ------------------------------------------ during F2F meeting we decided to support this feature > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:02:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 06:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-471: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:30:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 06:30:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-490: ------------------------------------- Labels: F2F2016 (was: ) > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:31:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 06:31:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-490: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:31:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 06:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289785#comment-13289785 ] Antoine Sabot-Durand commented on CDI-490: ------------------------------------------ During F2F we proposed choosing option 2). > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, ?AfterTypeDiscovery event?.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:36:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 06:36:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288971#comment-13288971 ] Antoine Sabot-Durand edited comment on CDI-527 at 9/7/16 6:35 AM: ------------------------------------------------------------------ In F2F meeting we decided to add "ignoreFinalMethod" method to {{ProcessBeanAttribute}}. Adding support for @WithAnnotations on the ProcessBeanAttributes (CDI-270) will also help to create team specific annotation allow this. was (Author: antoinesabot-durand): In F2F meeting we decided to add "ignoreFinalMethod" method. Adding support for @WithAnnotations on the ProcessBeanAttributes (CDI-270) will also help to create team specific annotation allow this. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:06:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 7 Sep 2016 07:06:00 -0400 (EDT) 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=13289818#comment-13289818 ] Stephan Knitelius commented on CDI-224: --------------------------------------- I am not so keen on adding another annotation or defining an element on Decorator. Wouldn't it be sufficient to define something along the lines: {quote} If a decorator extends a bean, the decorator's type is inferred from the parent. {quote} I don't see how this would cause backwards-compatibility issues, since the behavior of interface based decorators remains unchanged. > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:24:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 07:24:00 -0400 (EDT) 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=13289828#comment-13289828 ] Antoine Sabot-Durand commented on CDI-224: ------------------------------------------ We thought about this [~sknitelius], but we may have existing decorator extending class providing them helpers methods, so it won't work. > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:25:01 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 7 Sep 2016 07:25:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289830#comment-13289830 ] John Ament commented on CDI-471: -------------------------------- Ok, but is the support intended to be inclusive in nature? So to inject this I need both qualifiers present on my injection point, or either? > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:27:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 7 Sep 2016 07:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289832#comment-13289832 ] John Ament commented on CDI-420: -------------------------------- {{}} sounds cool, but doesn't seem to describe what the behavior is. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Wed Sep 7 07:30:34 2016 From: john.ament at spartasystems.com (John Ament) Date: Wed, 7 Sep 2016 11:30:34 +0000 Subject: [cdi-dev] Proposal for CDI-580 (intercepors for producers and custom beans) In-Reply-To: References: Message-ID: Overall, I like it. It does expose one of the problems with our builder pattern, in that you need to go into a child to do some useful work (e.g. add Transactional). That part might be worth cleaning up in a follow up ticket. John ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Wednesday, September 7, 2016 4:22 AM To: cdi-dev Subject: [cdi-dev] Proposal for CDI-580 (intercepors for producers and custom beans) Hi all, Please review this proposal we made during F2F meeting regarding CDI-580: https://github.com/cdi-spec/cdi/tree/CDI-580 [https://avatars0.githubusercontent.com/u/2632663?v=3&s=400] cdi-spec/cdi github.com cdi - CDI specification New spi interface is: https://github.com/antoinesd/cdi-spec/blob/c68730d294e614eee127288d7daa897e51db34bf/api/src/main/java/javax/enterprise/inject/spi/InterceptionProxyFactory.java usage is here: https://github.com/antoinesd/cdi-spec/tree/c68730d294e614eee127288d7daa897e51db34bf/api/src/test/java/org/jboss/cdi/api/test/interceptortricks Antoine ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160907/55a9435b/attachment.html From issues at jboss.org Wed Sep 7 07:33:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 7 Sep 2016 07:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289838#comment-13289838 ] Mark Struberg commented on CDI-420: ----------------------------------- Our first draft was {quote} {quote} But we all agreed, that it would be a tad too much. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:33:01 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 7 Sep 2016 07:33:01 -0400 (EDT) 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=13289839#comment-13289839 ] Matej Novotny commented on CDI-224: ----------------------------------- [~sknitelius] another food for thoughts - up until now, the delegate was an interface, therefore it only gave you access to methods. Having a delegate as a class will allow user to access fields which may lead to further user errors (as they are null mostly - you are on a proxy object). > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:36:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Wed, 7 Sep 2016 07:36:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289843#comment-13289843 ] John Ament commented on CDI-420: -------------------------------- Why not {{}} (I'm kidding)? It needs a good term. I like the idea, but the naming needs to be better for it to be usable I think. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:53:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Wed, 7 Sep 2016 07:53:00 -0400 (EDT) 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=13289855#comment-13289855 ] Stephan Knitelius commented on CDI-224: --------------------------------------- [~antoinesabot-durand] That does make life more difficult, but would it really hurt if the Decorator would also be applied in case of "helper class extension". Since those are highly unlikely to be injected? [~thenovot] Yes, however I don't see how the user error risk outways the benefit, it would also be true if a different annotation would be introduced or adding a new element to @Decorator. Alternatively, the type could be inferred from the @Delegate injection in case of extension. Another option which pops to mind, not my favorite, is declaring the to be decorated type in the annotation @Decorator(MyRealBean.class). This could then override the interface type inference and be mandatory for extension. > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > According to CDI 1.0 Spec: > "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." > "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." > Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. > I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. > {code} > import javax.decorator.Decorator; > import javax.decorator.Delegate; > import javax.enterprise.inject.Any; > import javax.inject.Inject; > import junit.framework.Assert; > import org.jboss.arquillian.container.test.api.Deployment; > import org.jboss.arquillian.junit.Arquillian; > import org.jboss.shrinkwrap.api.ShrinkWrap; > import org.jboss.shrinkwrap.api.spec.WebArchive; > import org.jboss.shrinkwrap.impl.BeansXml; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class DecoratesClassTestCase { > @Deployment > public static WebArchive create() { > return ShrinkWrap.create(WebArchive.class) > .addAsWebInfResource( > new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); > } > > @Test > public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { > Assert.assertEquals("Decorated Test", business.send("Test")); > } > > @Decorator > public static abstract class BusinessDecorator extends BusinessObject { > @Inject @Delegate @Any > private BusinessObject delegate; > > public String send(String msg) { > return "Decorated " + delegate.send(msg); > } > } > > public static class BusinessObject { > > public String send(String msg) { > return msg; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 08:03:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 7 Sep 2016 08:03:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289866#comment-13289866 ] Mark Struberg commented on CDI-420: ----------------------------------- other candidates have been {code} {code} trim just stuck out the most as it's always in conjunction with > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 08:06:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 08:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-220. ------------------------------------ Resolution: Rejected Already specified (look at 1st comment) > behaviour of CDI bean @Specializes session bean is undefined > ------------------------------------------------------------ > > Key: CDI-220 > URL: https://issues.jboss.org/browse/CDI-220 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.0, 1.1.EDR > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, F2F2016 > Fix For: 2.0 (discussion) > > > The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g. > @Stateless > public class Horse {..} > @ApplicationScoped @Specializes > public class Trakehner extends Horse {..} > Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error. > Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From builds at travis-ci.org Wed Sep 7 09:16:34 2016 From: builds at travis-ci.org (Travis CI) Date: Wed, 07 Sep 2016 13:16:34 +0000 Subject: [cdi-dev] Errored: cdi-spec/cdi#51 (CDI-580 - 8dfb614) In-Reply-To: Message-ID: <57d0133294943_33fd72f2c5bc860253@f3b68199-c419-4988-aaf7-9b55725c26b4.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #51 Status: Errored Duration: 6 minutes and 58 seconds Commit: 8dfb614 (CDI-580) Author: Antoine Sabot-Durand Message: Proposal for CDI-580 : Allow interceptors and decorators to be applied to the return value of a producer method Also works for custom beans create() View the changeset: https://github.com/cdi-spec/cdi/compare/c68730d294e6...8dfb6148da87 View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/158169982 -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160907/c63f287f/attachment.html From issues at jboss.org Wed Sep 7 09:51:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 09:51:00 -0400 (EDT) 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:all-tabpanel ] Antoine Sabot-Durand updated CDI-224: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Support Decoration of no interface beans > ---------------------------------------- > > Key: CDI-224 > URL: https://issues.jboss.org/browse/CDI-224 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > 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 Wed Sep 7 12:24:48 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 07 Sep 2016 16:24:48 +0000 Subject: [cdi-dev] EDR2 officially launched Message-ID: Hi all, In case you didn't notice, JCP has finally published our EDR2 last week-end ;). I'm preparing a blog post for that. Regarding our work, I've now put the master branch as the default one in the repo. All the (numerous ;) ) PRs will be done against master from now. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160907/8abdb837/attachment.html From issues at jboss.org Wed Sep 7 12:32:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 12:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290063#comment-13290063 ] Antoine Sabot-Durand commented on CDI-626: ------------------------------------------ F2F decided to treat CDI.current() as IllegalStateException when CDI is not available. It's the current API behaviour. > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 12:32:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 12:32:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-626: ---------------------------------------- Assignee: Antoine Sabot-Durand > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 12:33:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 12:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-626 started by Antoine Sabot-Durand. ------------------------------------------------ > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 12:50:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Sep 2016 12:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290063#comment-13290063 ] Antoine Sabot-Durand edited comment on CDI-626 at 9/7/16 12:49 PM: ------------------------------------------------------------------- F2F decided to treat CDI.current() as IllegalStateException when CDI is not available. It's the current API behaviour. Javadoc needs to be clarified on that point. was (Author: antoinesabot-durand): F2F decided to treat CDI.current() as IllegalStateException when CDI is not available. It's the current API behaviour. > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Wed Sep 7 13:03:38 2016 From: john.ament at spartasystems.com (John Ament) Date: Wed, 7 Sep 2016 17:03:38 +0000 Subject: [cdi-dev] What to do to move CDI-30/PR 296 Forward Message-ID: All, It seems like we're still stuck on CDI-30. Its been open, last activity on Aug 2. I would love to see it closed and only reference the use case agreed to - another library wants to integrate CDI into its stack. To do so, it wants to be able to start and stop the built in contexts. John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160907/8f76d178/attachment.html From struberg at yahoo.de Wed Sep 7 16:08:03 2016 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 7 Sep 2016 20:08:03 +0000 (UTC) Subject: [cdi-dev] What to do to move CDI-30/PR 296 Forward In-Reply-To: References: Message-ID: <945764114.506964.1473278883963@mail.yahoo.com> We have been burning our brains over this very topic, but it doesn't yet feel sound. So I guess we will give it another few days/weeks to tinker with it. The main downside of this api is that it's actually only useful for the request context and only in SE. But we still add an API which looks to the user as it could use it for e.g. the ConversationContext, or existing servlet requests etc. It's complicated... I think we will first incorporate the parts which we found really nice solutions for. * Interceptor/Decorator for producer methods and custom Bean implementations * bean-discovery without automatically picking up all classes as @Dependent * A few other minor tickets Should not take that long. After that we will have to tackle CDI-30 for sure. LieGrue, strub On Wednesday, 7 September 2016, 19:04, John Ament wrote: >All, > > >It seems like we're still stuck on CDI-30. Its been open, last activity on Aug 2. I would love to see it closed and only reference the use case agreed to - another library wants to integrate CDI into its stack. To do so, it wants to be able to start and stop the built in contexts. > > >John > From struberg at yahoo.de Wed Sep 7 16:13:15 2016 From: struberg at yahoo.de (Mark Struberg) Date: Wed, 7 Sep 2016 20:13:15 +0000 (UTC) Subject: [cdi-dev] Proposal for CDI-580 (intercepors for producers and custom beans) In-Reply-To: References: Message-ID: <348484654.504441.1473279195624@mail.yahoo.com> Yes, it was quite tricky to get the details right. E.g. handling the CreationalContext correctly so that we can later cleanly destroy all Interceptor/Decorator instances if at the end of the life-span the Bean#destroy() gets invoked. There are a lot of internal details to consider and it took us 2 hours to expose enough to give the user almost the full control, but as less as possible of the internal details to not have him mess up our Container. LieGrue, strub On Wednesday, 7 September 2016, 13:31, John Ament wrote: > > >Overall, I like it. It does expose one of the problems with our builder pattern, in that you need to go into a child to do some useful work (e.g. add Transactional). That part might be worth cleaning up in a follow up ticket. > > >John > > > >________________________________ > >From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand >Sent: Wednesday, September 7, 2016 4:22 AM >To: cdi-dev >Subject: [cdi-dev] Proposal for CDI-580 (intercepors for producers and custom beans) > >Hi all, > > >Please review this proposal we made during F2F meeting regarding CDI-580: > > >https://github.com/cdi-spec/cdi/tree/CDI-580 > cdi-spec/cdi >github.com >cdi - CDI specification > > > > > >New spi interface is: https://github.com/antoinesd/cdi-spec/blob/c68730d294e614eee127288d7daa897e51db34bf/api/src/main/java/javax/enterprise/inject/spi/InterceptionProxyFactory.java > > >usage is here: >https://github.com/antoinesd/cdi-spec/tree/c68730d294e614eee127288d7daa897e51db34bf/api/src/test/java/org/jboss/cdi/api/test/interceptortricks > > >Antoine >________________________________ > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. > >_______________________________________________ >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 john.ament at spartasystems.com Wed Sep 7 17:11:07 2016 From: john.ament at spartasystems.com (John Ament) Date: Wed, 7 Sep 2016 21:11:07 +0000 Subject: [cdi-dev] What to do to move CDI-30/PR 296 Forward In-Reply-To: <945764114.506964.1473278883963@mail.yahoo.com> References: , <945764114.506964.1473278883963@mail.yahoo.com> Message-ID: That's kind of an odd response. How does CDI-30 only work for request context? What makes you believe that? Same for SE only. John ________________________________ From: Mark Struberg Sent: Wednesday, September 7, 2016 4:08 PM To: John Ament; Cdi-dev Subject: Re: [cdi-dev] What to do to move CDI-30/PR 296 Forward We have been burning our brains over this very topic, but it doesn't yet feel sound. So I guess we will give it another few days/weeks to tinker with it. The main downside of this api is that it's actually only useful for the request context and only in SE. But we still add an API which looks to the user as it could use it for e.g. the ConversationContext, or existing servlet requests etc. It's complicated... I think we will first incorporate the parts which we found really nice solutions for. * Interceptor/Decorator for producer methods and custom Bean implementations * bean-discovery without automatically picking up all classes as @Dependent * A few other minor tickets Should not take that long. After that we will have to tackle CDI-30 for sure. LieGrue, strub On Wednesday, 7 September 2016, 19:04, John Ament wrote: >All, > > >It seems like we're still stuck on CDI-30. Its been open, last activity on Aug 2. I would love to see it closed and only reference the use case agreed to - another library wants to integrate CDI into its stack. To do so, it wants to be able to start and stop the built in contexts. > > >John > ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160907/85fd1a46/attachment-0001.html From builds at travis-ci.org Thu Sep 8 03:03:42 2016 From: builds at travis-ci.org (Travis CI) Date: Thu, 08 Sep 2016 07:03:42 +0000 Subject: [cdi-dev] Passed: cdi-spec/cdi#54 (EDR2-with-assertions - ab444df) In-Reply-To: Message-ID: <57d10d501e3d9_33f91dec8ec401084750@ea16e9d5-41d2-49b4-81f0-927991872448.mail> Build Update for cdi-spec/cdi ------------------------------------- Build: #54 Status: Passed Duration: 4 minutes and 18 seconds Commit: ab444df (EDR2-with-assertions) Author: Tomas Remes Message: Update paths to latest master. View the changeset: https://github.com/cdi-spec/cdi/compare/f7a2e81075d9^...ab444df7447f View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/158375957 -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160908/2f690dc5/attachment.html From mkouba at redhat.com Thu Sep 8 03:05:53 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 8 Sep 2016 09:05:53 +0200 Subject: [cdi-dev] What to do to move CDI-30/PR 296 Forward In-Reply-To: References: <945764114.506964.1473278883963@mail.yahoo.com> Message-ID: Dne 7.9.2016 v 23:11 John Ament napsal(a): > That's kind of an odd response. > > > How does CDI-30 only work for request context? What makes you believe > that? @RequestScoped - makes sense @ApplicationScoped - is usually always active, no activation needed @SessionScoped - activate/deactivate is not enough, you have to associate the context with some storage @ConversationScoped - even more complicated, you need a storage and conversation ids > > > John > > > > ------------------------------------------------------------------------ > *From:* Mark Struberg > *Sent:* Wednesday, September 7, 2016 4:08 PM > *To:* John Ament; Cdi-dev > *Subject:* Re: [cdi-dev] What to do to move CDI-30/PR 296 Forward > > We have been burning our brains over this very topic, but it doesn't yet > feel sound. So I guess we will give it another few days/weeks to tinker > with it. > > The main downside of this api is that it's actually only useful for the > request context and only in SE. But we still add an API which looks to > the user as it could use it for e.g. the ConversationContext, or > existing servlet requests etc. It's complicated... > > I think we will first incorporate the parts which we found really nice > solutions for. > > * Interceptor/Decorator for producer methods and custom Bean > implementations > * bean-discovery without automatically picking up all classes as @Dependent > * A few other minor tickets > > > Should not take that long. After that we will have to tackle CDI-30 for > sure. > > > LieGrue, > strub > > > > On Wednesday, 7 September 2016, 19:04, John Ament > wrote: >>All, >> >> >>It seems like we're still stuck on CDI-30. Its been open, last activity on Aug 2. I would love to see it closed and only reference the use case agreed to - another library wants to integrate CDI into its stack. To do so, it wants to be able to start and stop the built in contexts. >> >> >>John >> > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > 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 Sep 8 03:36:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 8 Sep 2016 03:36:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290262#comment-13290262 ] Martin Kouba commented on CDI-471: ---------------------------------- [~meetoblivion] The set of qualifiers of the producer method {{producerTemplate()}} from the description above should just contain both {{@ContextName("ctx1")}} and {{@ContextName("ctx2")}}. So all the following injection points should resolve to the producer method as the bean has all the required qualifiers: {{@Inject @ContextName("ctx1") ProducerTemplate}}, {{@Inject @ContextName("ctx2") ProducerTemplate}} , {{@Inject @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate}}. > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Thu Sep 8 03:51:58 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 08 Sep 2016 07:51:58 +0000 Subject: [cdi-dev] What to do to move CDI-30/PR 296 Forward In-Reply-To: References: <945764114.506964.1473278883963@mail.yahoo.com> Message-ID: John, Martin, I think we really need to have a video hangout with you 2 and Mark to restart discussion on the topic. What are your availability for such a meeting? Antoine On Thu, Sep 8, 2016 at 9:06 AM Martin Kouba wrote: > Dne 7.9.2016 v 23:11 John Ament napsal(a): > > That's kind of an odd response. > > > > > > How does CDI-30 only work for request context? What makes you believe > > that? > > @RequestScoped - makes sense > @ApplicationScoped - is usually always active, no activation needed > @SessionScoped - activate/deactivate is not enough, you have to > associate the context with some storage > @ConversationScoped - even more complicated, you need a storage and > conversation ids > > > > > > > John > > > > > > > > ------------------------------------------------------------------------ > > *From:* Mark Struberg > > *Sent:* Wednesday, September 7, 2016 4:08 PM > > *To:* John Ament; Cdi-dev > > *Subject:* Re: [cdi-dev] What to do to move CDI-30/PR 296 Forward > > > > We have been burning our brains over this very topic, but it doesn't yet > > feel sound. So I guess we will give it another few days/weeks to tinker > > with it. > > > > The main downside of this api is that it's actually only useful for the > > request context and only in SE. But we still add an API which looks to > > the user as it could use it for e.g. the ConversationContext, or > > existing servlet requests etc. It's complicated... > > > > I think we will first incorporate the parts which we found really nice > > solutions for. > > > > * Interceptor/Decorator for producer methods and custom Bean > > implementations > > * bean-discovery without automatically picking up all classes as > @Dependent > > * A few other minor tickets > > > > > > Should not take that long. After that we will have to tackle CDI-30 for > > sure. > > > > > > LieGrue, > > strub > > > > > > > > On Wednesday, 7 September 2016, 19:04, John Ament > > wrote: > >>All, > >> > >> > >>It seems like we're still stuck on CDI-30. Its been open, last activity > on Aug 2. I would love to see it closed and only reference the use case > agreed to - another library wants to integrate CDI into its stack. To do > so, it wants to be able to start and stop the built in contexts. > >> > >> > >>John > >> > > ------------------------------------------------------------------------ > > NOTICE: This e-mail message and any attachments may contain > > confidential, proprietary, and/or privileged information which should be > > treated accordingly. If you are not the intended recipient, please > > notify the sender immediately by return e-mail, delete this message, and > > destroy all physical and electronic copies. Thank you. > > > > > > _______________________________________________ > > 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/20160908/53497cf2/attachment-0001.html From issues at jboss.org Thu Sep 8 04:11:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 8 Sep 2016 04:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: Mark Struberg created CDI-627: --------------------------------- Summary: fix wording regression for beans.xml alternative check introduced in 1.2 Key: CDI-627 URL: https://issues.jboss.org/browse/CDI-627 Project: CDI Specification Issues Issue Type: Bug Components: Concepts Affects Versions: 1.2.Final Reporter: Mark Struberg My scenario is the following: I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. {code} @Alternative @ApplicationScoped @Exclude(ifProjectStage=Production.class) public class MockMailService implements MailService {...} {code} Of course I only need to activate it in beans.xml: {code} org.acme.MockMailService {code} This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! What the intention was: all is fine IF one of * There exists a class T with the given name * That class T (or a contained producer field or producer method) is annotated with @Alternative * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 04:28:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 8 Sep 2016 04:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290305#comment-13290305 ] Matej Novotny commented on CDI-627: ----------------------------------- To clarify, the deal is the following (please correct me if I am wrong [~struberg]): * *In CDI 1.0* -> If there is ** with the specified name, or if the class with the specified name is not an alternative bean class, the container automatically detects the problem and treats it as a deployment problem. * *Current state of spec* -> If there is ** whose bean class has the specified name, or if no bean whose bean class has the specified name is an alternative, the container automatically detects the problem and treats it as a deployment problem. So basically by Vetoing the alternative (or excluding) it does not become a bean, hence the {{beans.xml}} will be considered invalid. > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 04:38:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Thu, 8 Sep 2016 04:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: Stephan Knitelius created CDI-628: ------------------------------------- Summary: Allow overriding of Scope at Injection Point Key: CDI-628 URL: https://issues.jboss.org/browse/CDI-628 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 2.0 (proposed) Reporter: Stephan Knitelius Priority: Optional Allow overriding scopes at injection point. {code} @SessionScope public class FeatureState {...} public class Bean B { @Inject @ConversationScoped //Overriding original scope public BeanA beanA; ... } {code} Sample use-case for for a feature flag: {code} @Alternative public class FeatureStateProducer { @Inject @SessionScoped private FeatureState devState; @Inject @ConversationScoped private FeatureState viewState; @Inject private JNDIProvider jndiProvider; private boolean viewOnly = true; @PostConstruct public void postConstruct() { this.viewMode = ...; //read config. } @Produces public FeatureState produce() { return viewOnly ? viewState : devState; } } {code} Currently this can be solved by overriding scope with @Qualifiers: {code} @ViewMode @ConversationScoped public class ViewFeatureState extends FeatureState {...} @DevMode @SessionScoped public class DevFeatureState extends FeatureState {...} {code} Risks: * developers might start to define the scopes at IP and on bean (hard to maintain). * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 04:38:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Thu, 8 Sep 2016 04:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Knitelius updated CDI-628: ---------------------------------- Priority: Minor (was: Optional) > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 04:45:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 8 Sep 2016 04:45:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-627: ------------------------------------- Fix Version/s: 2.0 (proposed) > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 04:47:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 8 Sep 2016 04:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290321#comment-13290321 ] Antoine Sabot-Durand commented on CDI-627: ------------------------------------------ [~tremes] Do we have related test in TCK in 1.0 and did it changed in 1.1? > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 04:53:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 8 Sep 2016 04:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-620 started by Antoine Sabot-Durand. ------------------------------------------------ > Not clear what the id for an annotated type is. > ----------------------------------------------- > > Key: CDI-620 > URL: https://issues.jboss.org/browse/CDI-620 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. > In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 05:00:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 8 Sep 2016 05:00:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290334#comment-13290334 ] Romain Manni-Bucau commented on CDI-628: ---------------------------------------- Looks like breaking CDI concept to me (loose coupling since you need to know what you inject handling the scope at that level) and already doable through an extension so not sure it should be a core feature or a feature flipping library > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Thu Sep 8 05:02:45 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 8 Sep 2016 11:02:45 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? Message-ID: Hi, The CDI spec defines a built-in bean for the type HttpServletRequest. In 3.8 it says: "A servlet container must provide the following built-in beans, all of which have qualifier @Default: a bean with bean type javax.servlet.http.HttpServletRequest, allowing injection of a reference to the HttpServletRequest" An HttpServletRequest however can be wrapped multiple times and by multiple artefacts. I.e. by a ServerAuthModule, Filter and a RequestDispatcher. The question now is; which version of the HttpServletRequest is supposed to be injected? * The first one in the chain? * The last one in the chain? * The current one at a given point in the chain? A little bit of experimenting seems to indicate it's now often "one of the first ones", e.g. the one that happened to be current when e.g. a ServletRequestListener that initialises a specific CDI implementation is called. I think this is a little confusing, as working with an injected request can now totally ignore the request wrapping that has been done and break an application badly. Thoughts? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160908/d7352a48/attachment.html From issues at jboss.org Thu Sep 8 05:09:01 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 8 Sep 2016 05:09:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290342#comment-13290342 ] Mark Struberg commented on CDI-627: ----------------------------------- [~manovotn] Yes, that's pretty much it. In CDI 1.0 the check was *intentionally* on the Class. Of course in CDI 1.0 it was not possible to add custom beans which return isAlternative()==true. Otoh if you already have an Extension then it's also really easy to veto the original bean to prevent AmbiguousResolutionExceptions. I now like to allow both cases. > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 05:14:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Thu, 8 Sep 2016 05:14:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290346#comment-13290346 ] Stephan Knitelius commented on CDI-628: --------------------------------------- [~rmannibucau] agree with you on that. Just a bit unsure, so I put it out there to spit ball the idea. > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 05:15:02 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 8 Sep 2016 05:15:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290348#comment-13290348 ] Martin Kouba commented on CDI-628: ---------------------------------- -1 Not only this could break a lot of things but also redefines the concept of a bean, i.e. a bean has a single scope. Also imagine scenarios like {{@Inject @SessionScoped}} for a bean which originally has a non-passivating scope and similar... > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 05:24:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 8 Sep 2016 05:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290359#comment-13290359 ] Matej Novotny commented on CDI-628: ----------------------------------- The current solution you mentioned with qualifiers doesn't actually do the same thing. By creating two classes with different qualifiers you also creates two new bean _types_ along with it. And each of those new types will/can have a different scope. While the feature you suggests says that the very same bean could have more scopes. -1 for this, also Martin is right on the passivation topic. > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 05:28:01 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Thu, 8 Sep 2016 05:28:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290365#comment-13290365 ] Stephan Knitelius commented on CDI-628: --------------------------------------- [~manovotn] it is just meant to show that there is a possible work around :) As stated, I am not really for it, I just wanted to spit ball the idea. > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 05:34:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 8 Sep 2016 05:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290370#comment-13290370 ] Martin Kouba commented on CDI-627: ---------------------------------- {quote} What the intention was: all is fine IF one of There exists a class T with the given name That class T (or a contained producer field or producer method) is annotated with @Alternative There is a Bean with isAlternative() == true {quote} Hm, then the only requirement is _"a class with the given name must be on the classpath"_. Because if *it is*, the following items are irrelevant and if *it's not* the following requirements cannot be fullfilled. > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 05:37:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 8 Sep 2016 05:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290372#comment-13290372 ] Mark Struberg commented on CDI-627: ----------------------------------- No Martin, I think in that case we miss if people ass java.lang.Object It really needs to be a 'candidate' to be an @Alternative at least imo. So either it originally was an @Alternative, or it gets made to one via Extensions. Enlisting other classes should imo fail. > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Thu Sep 8 06:23:57 2016 From: john.ament at spartasystems.com (John Ament) Date: Thu, 8 Sep 2016 10:23:57 +0000 Subject: [cdi-dev] What to do to move CDI-30/PR 296 Forward In-Reply-To: References: <945764114.506964.1473278883963@mail.yahoo.com> , Message-ID: TBH, its not going to happen for me before J1. ________________________________ From: Antoine Sabot-Durand Sent: Thursday, September 8, 2016 3:51 AM To: Martin Kouba; John Ament; cdi-dev; Mark Struberg Subject: Re: [cdi-dev] What to do to move CDI-30/PR 296 Forward John, Martin, I think we really need to have a video hangout with you 2 and Mark to restart discussion on the topic. What are your availability for such a meeting? Antoine On Thu, Sep 8, 2016 at 9:06 AM Martin Kouba > wrote: Dne 7.9.2016 v 23:11 John Ament napsal(a): > That's kind of an odd response. > > > How does CDI-30 only work for request context? What makes you believe > that? @RequestScoped - makes sense @ApplicationScoped - is usually always active, no activation needed @SessionScoped - activate/deactivate is not enough, you have to associate the context with some storage @ConversationScoped - even more complicated, you need a storage and conversation ids > > > John > > > > ------------------------------------------------------------------------ > *From:* Mark Struberg > > *Sent:* Wednesday, September 7, 2016 4:08 PM > *To:* John Ament; Cdi-dev > *Subject:* Re: [cdi-dev] What to do to move CDI-30/PR 296 Forward > > We have been burning our brains over this very topic, but it doesn't yet > feel sound. So I guess we will give it another few days/weeks to tinker > with it. > > The main downside of this api is that it's actually only useful for the > request context and only in SE. But we still add an API which looks to > the user as it could use it for e.g. the ConversationContext, or > existing servlet requests etc. It's complicated... > > I think we will first incorporate the parts which we found really nice > solutions for. > > * Interceptor/Decorator for producer methods and custom Bean > implementations > * bean-discovery without automatically picking up all classes as @Dependent > * A few other minor tickets > > > Should not take that long. After that we will have to tackle CDI-30 for > sure. > > > LieGrue, > strub > > > > On Wednesday, 7 September 2016, 19:04, John Ament > > wrote: >>All, >> >> >>It seems like we're still stuck on CDI-30. Its been open, last activity on Aug 2. I would love to see it closed and only reference the use case agreed to - another library wants to integrate CDI into its stack. To do so, it wants to be able to start and stop the built in contexts. >> >> >>John >> > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > 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. ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160908/4742afb7/attachment.html From issues at jboss.org Thu Sep 8 06:28:03 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 8 Sep 2016 06:28:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290412#comment-13290412 ] John Ament commented on CDI-471: -------------------------------- Ok, then we need to make sure the spec wording states that they behavior like any other qualifier. Meaning if I had the following producers: {code} @Produces @ContextName("ctx1") ProducerTemplate pt1; @Produces @ContextName("ctx2") ProducerTemplate pt2; {code} And an injection point: {code} @inject @ContextName("ctx1") @ContextName("ctx2") private ProducerTemplate pt; {code} I would get no beans satisfying.. likewise, if I had the following producers: {code} @Produces @ContextName("ctx1") ProducerTemplate pt1; @Produces @ContextName("ctx2") ProducerTemplate pt2; @Produces @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate pt; {code} and injection points: {code} @inject @ContextName("ctx1") @ContextName("ctx2") private ProducerTemplate pt0; @inject @ContextName("ctx1") private ProducerTemplate pt1; @inject @ContextName("ctx2") private ProducerTemplate pt2; {code} The first injection point would work fine, however the second and third would give an ambiguous bean resolution, as behaves today. > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:29:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 8 Sep 2016 06:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290412#comment-13290412 ] John Ament edited comment on CDI-471 at 9/8/16 6:28 AM: -------------------------------------------------------- Ok, then we need to make sure the spec wording states that they behave like any other qualifier. Meaning if I had the following producers: {code} @Produces @ContextName("ctx1") ProducerTemplate pt1; @Produces @ContextName("ctx2") ProducerTemplate pt2; {code} And an injection point: {code} @inject @ContextName("ctx1") @ContextName("ctx2") private ProducerTemplate pt; {code} I would get no beans satisfying.. likewise, if I had the following producers: {code} @Produces @ContextName("ctx1") ProducerTemplate pt1; @Produces @ContextName("ctx2") ProducerTemplate pt2; @Produces @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate pt; {code} and injection points: {code} @inject @ContextName("ctx1") @ContextName("ctx2") private ProducerTemplate pt0; @inject @ContextName("ctx1") private ProducerTemplate pt1; @inject @ContextName("ctx2") private ProducerTemplate pt2; {code} The first injection point would work fine, however the second and third would give an ambiguous bean resolution, as behaves today. was (Author: meetoblivion): Ok, then we need to make sure the spec wording states that they behavior like any other qualifier. Meaning if I had the following producers: {code} @Produces @ContextName("ctx1") ProducerTemplate pt1; @Produces @ContextName("ctx2") ProducerTemplate pt2; {code} And an injection point: {code} @inject @ContextName("ctx1") @ContextName("ctx2") private ProducerTemplate pt; {code} I would get no beans satisfying.. likewise, if I had the following producers: {code} @Produces @ContextName("ctx1") ProducerTemplate pt1; @Produces @ContextName("ctx2") ProducerTemplate pt2; @Produces @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate pt; {code} and injection points: {code} @inject @ContextName("ctx1") @ContextName("ctx2") private ProducerTemplate pt0; @inject @ContextName("ctx1") private ProducerTemplate pt1; @inject @ContextName("ctx2") private ProducerTemplate pt2; {code} The first injection point would work fine, however the second and third would give an ambiguous bean resolution, as behaves today. > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:31:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 8 Sep 2016 06:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290414#comment-13290414 ] John Ament commented on CDI-628: -------------------------------- It is possible to create a bean via a portable extension that has two different scopes - two different beans. The JMS spec leverages this to allow JMSContext to be injectable for both request scoped and transaction scoped. I would recommend that approach over the injection point overriding the scope. > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:34:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 8 Sep 2016 06:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290419#comment-13290419 ] Tomas Remes commented on CDI-627: --------------------------------- [~antoinesabot-durand] No there is no such test in TCK 1.0 which would assert that application is deployable with listed alternative which was vetoed/excluded in extension. [~struberg] How it can become a 'candidate' when it's not annotated @Alternative or it's just vetoed? It's just not possible IMO. bq. So either it originally was an @Alternative, .. There is no such term or condition. Either it is an alternative or not. > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:36:01 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 8 Sep 2016 06:36:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290422#comment-13290422 ] Mark Struberg commented on CDI-627: ----------------------------------- [~tremes] in my case it IS annotated with @Alternative. But it still blows up in the latest Weld version (Worked perfectly fine with Weld EE6 level). > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:37:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Thu, 8 Sep 2016 06:37:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290424#comment-13290424 ] Stephan Knitelius commented on CDI-628: --------------------------------------- [~meetoblivion] thanks for pointing that out, pretty sure we have come to the conclusion that this is a bad idea :) > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:38:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Thu, 8 Sep 2016 06:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290424#comment-13290424 ] Stephan Knitelius edited comment on CDI-628 at 9/8/16 6:37 AM: --------------------------------------------------------------- [~meetoblivion] thanks for pointing that out. I guess this can be rejected/closed. Hardly any benefit and a lot of very good points against it. was (Author: sknitelius): [~meetoblivion] thanks for pointing that out, pretty sure we have come to the conclusion that this is a bad idea :) > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:40:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 8 Sep 2016 06:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290428#comment-13290428 ] Tomas Remes commented on CDI-627: --------------------------------- [~struberg] Can you please provide link to the test when it passes? > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Thu Sep 8 06:40:40 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 8 Sep 2016 12:40:40 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: Message-ID: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Hi Arjan, that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.requestInitialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used. But TBH I don't think we can fix this easily as I'm not aware of any portable way to listen for "wrapping actions". Martin Dne 8.9.2016 v 11:02 arjan tijms napsal(a): > Hi, > > The CDI spec defines a built-in bean for the type HttpServletRequest. In > 3.8 it says: > > "A servlet container must provide the following built-in beans, all of > which have qualifier @Default: > > a bean with bean type javax.servlet.http.HttpServletRequest, allowing > injection of a reference to the HttpServletRequest" > > An HttpServletRequest however can be wrapped multiple times and by > multiple artefacts. I.e. by a ServerAuthModule, Filter and a > RequestDispatcher. > > The question now is; which version of the HttpServletRequest is supposed > to be injected? > > * The first one in the chain? > * The last one in the chain? > * The current one at a given point in the chain? > > A little bit of experimenting seems to indicate it's now often "one of > the first ones", e.g. the one that happened to be current when e.g. a > ServletRequestListener that initialises a specific CDI implementation is > called. > > I think this is a little confusing, as working with an injected request > can now totally ignore the request wrapping that has been done and break > an application badly. > > Thoughts? > > Kind regards, > Arjan Tijms > > > > _______________________________________________ > 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 Sep 8 06:50:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 8 Sep 2016 06:50:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290436#comment-13290436 ] Martin Kouba commented on CDI-471: ---------------------------------- Yes John, exactly! > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 06:53:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 8 Sep 2016 06:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290442#comment-13290442 ] Martin Kouba commented on CDI-628: ---------------------------------- Just a note - JMS wording and solution/impl is IMHO also not correct from the CDI point of view. Because, for the same IP you should get different beans depending on the TX status and this is normally an ambiguous resolution, so they have to implement some kind of delagation bean injected and forwarding the calls to either {{@RequestScoped}} or {{@TransactionScoped}} implementation. > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Thu Sep 8 07:03:04 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 8 Sep 2016 13:03:04 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Hi, On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba wrote: > that's a good question. In Weld, the request object is captured during > request context activation, i.e. during ServletRequestListener.requestInitialized() > notification and before any filter or servlet is invoked. So wrappers are > ignored and the original/first request is used. > Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.requestInitialized() notification rather late, and do that after the application already has seen the request and has had a chance to wrap it. This by itself is a separate problem. So on these servers, Weld would receive an early request but not necessarily the earliest. > But TBH I don't think we can fix this easily as I'm not aware of any > portable way to listen for "wrapping actions". > This would have to happen with Server specific code I guess, just as Weld now requires an SPI to obtain the current principal for injection. You could say that the Servlet container could store the request "somewhere" on a stack structure, just before it invokes the ServerAuthModule, Filter, Servlet and anything else I may have forgotten, and then when control flows back to each Servlet, Filter, etc unwind that stack. At the very least the spec for now should perhaps clarify this? Kind regards, Arjan Tijms > > Martin > > Dne 8.9.2016 v 11:02 arjan tijms napsal(a): > >> Hi, >> >> The CDI spec defines a built-in bean for the type HttpServletRequest. In >> 3.8 it says: >> >> "A servlet container must provide the following built-in beans, all of >> which have qualifier @Default: >> >> a bean with bean type javax.servlet.http.HttpServletRequest, allowing >> injection of a reference to the HttpServletRequest" >> >> An HttpServletRequest however can be wrapped multiple times and by >> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >> RequestDispatcher. >> >> The question now is; which version of the HttpServletRequest is supposed >> to be injected? >> >> * The first one in the chain? >> * The last one in the chain? >> * The current one at a given point in the chain? >> >> A little bit of experimenting seems to indicate it's now often "one of >> the first ones", e.g. the one that happened to be current when e.g. a >> ServletRequestListener that initialises a specific CDI implementation is >> called. >> >> I think this is a little confusing, as working with an injected request >> can now totally ignore the request wrapping that has been done and break >> an application badly. >> >> Thoughts? >> >> Kind regards, >> Arjan Tijms >> >> >> >> _______________________________________________ >> 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/license >> s/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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160908/78fc0e05/attachment.html From rmannibucau at gmail.com Thu Sep 8 07:09:42 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 8 Sep 2016 13:09:42 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Hit that issue as well several times. It is more vicious than it looks like IMO cause CDI will *never* get *the* right request for everybody, it is as simple as that. Any part of the app can rely on the wrapper level N (of course N being different for each mentionned parts of the app). Best CDI can do is to provide the request it has (already the case and cost pretty much nothing) and enable the user to produces very easily its own request from its filter (or equivalent) for its usage IMO - which is IMO already doable but maybe there is another shortcut we can introduce I didnt think about. If you look one step further any web framework built on top of CDI does it and therefore runs in a well known context. Romain Manni-Bucau @rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | Tomitriber | JavaEE Factory 2016-09-08 13:03 GMT+02:00 arjan tijms : > Hi, > > On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba wrote: > >> that's a good question. In Weld, the request object is captured during >> request context activation, i.e. during ServletRequestListener.requestInitialized() >> notification and before any filter or servlet is invoked. So wrappers are >> ignored and the original/first request is used. >> > > Indeed, although do note that some servers (Liberty and WebLogic I think) > send the ServletRequestListener.requestInitialized() notification rather > late, and do that after the application already has seen the request and > has had a chance to wrap it. This by itself is a separate problem. So on > these servers, Weld would receive an early request but not necessarily the > earliest. > > >> But TBH I don't think we can fix this easily as I'm not aware of any >> portable way to listen for "wrapping actions". >> > > This would have to happen with Server specific code I guess, just as Weld > now requires an SPI to obtain the current principal for injection. > > You could say that the Servlet container could store the request > "somewhere" on a stack structure, just before it invokes the > ServerAuthModule, Filter, Servlet and anything else I may have forgotten, > and then when control flows back to each Servlet, Filter, etc unwind that > stack. > > At the very least the spec for now should perhaps clarify this? > > Kind regards, > Arjan Tijms > > > > >> >> Martin >> >> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >> >>> Hi, >>> >>> The CDI spec defines a built-in bean for the type HttpServletRequest. In >>> 3.8 it says: >>> >>> "A servlet container must provide the following built-in beans, all of >>> which have qualifier @Default: >>> >>> a bean with bean type javax.servlet.http.HttpServletRequest, allowing >>> injection of a reference to the HttpServletRequest" >>> >>> An HttpServletRequest however can be wrapped multiple times and by >>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >>> RequestDispatcher. >>> >>> The question now is; which version of the HttpServletRequest is supposed >>> to be injected? >>> >>> * The first one in the chain? >>> * The last one in the chain? >>> * The current one at a given point in the chain? >>> >>> A little bit of experimenting seems to indicate it's now often "one of >>> the first ones", e.g. the one that happened to be current when e.g. a >>> ServletRequestListener that initialises a specific CDI implementation is >>> called. >>> >>> I think this is a little confusing, as working with an injected request >>> can now totally ignore the request wrapping that has been done and break >>> an application badly. >>> >>> Thoughts? >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> _______________________________________________ >>> 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/license >>> s/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/20160908/ab4e63c2/attachment-0001.html From arjan.tijms at gmail.com Thu Sep 8 07:31:30 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 8 Sep 2016 13:31:30 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Hi, On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau wrote: > Hit that issue as well several times. > > It is more vicious than it looks like IMO cause CDI will *never* get *the* > right request for everybody, it is as simple as that. Any part of the app > can rely on the wrapper level N (of course N being different for each > mentionned parts of the app). > What I was thinking, but maybe I'm wrong, is that the application never "just" wraps the request and uses it for itself. It always passes it to the container, which then passes it on to the next Filter, Servlet, or whatever. So at that point the container code has the opportunity to store the request as being the "current" one. E.g. if you do: RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...); dispatcher.forward(wrap(request), response); Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available. The other way around, eventually every AuthModule, Filter or Servlet has to be called by the container at some point. E.g. the "protected void service(HttpServletRequest req, HttpServletResponse resp)" is called by the container. So just before the container invokes the HttpServlet#service method, the container can store the request, and CDI (via an SPI) can pick it up from there. That way in every context you can always have the *current* request (the request that's passed in to the last Servlet or Filter call on the stack). Kind regards, Arjan Tijms > Best CDI can do is to provide the request it has (already the case and > cost pretty much nothing) and enable the user to produces very easily its > own request from its filter (or equivalent) for its usage IMO - which is > IMO already doable but maybe there is another shortcut we can introduce I > didnt think about. If you look one step further any web framework built on > top of CDI does it and therefore runs in a well known context. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Wordpress Blog > | Github > | LinkedIn > | Tomitriber > | JavaEE Factory > > > 2016-09-08 13:03 GMT+02:00 arjan tijms : > >> Hi, >> >> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba wrote: >> >>> that's a good question. In Weld, the request object is captured during >>> request context activation, i.e. during ServletRequestListener.requestInitialized() >>> notification and before any filter or servlet is invoked. So wrappers are >>> ignored and the original/first request is used. >>> >> >> Indeed, although do note that some servers (Liberty and WebLogic I think) >> send the ServletRequestListener.requestInitialized() notification rather >> late, and do that after the application already has seen the request and >> has had a chance to wrap it. This by itself is a separate problem. So on >> these servers, Weld would receive an early request but not necessarily the >> earliest. >> >> >>> But TBH I don't think we can fix this easily as I'm not aware of any >>> portable way to listen for "wrapping actions". >>> >> >> This would have to happen with Server specific code I guess, just as Weld >> now requires an SPI to obtain the current principal for injection. >> >> You could say that the Servlet container could store the request >> "somewhere" on a stack structure, just before it invokes the >> ServerAuthModule, Filter, Servlet and anything else I may have forgotten, >> and then when control flows back to each Servlet, Filter, etc unwind that >> stack. >> >> At the very least the spec for now should perhaps clarify this? >> >> Kind regards, >> Arjan Tijms >> >> >> >> >>> >>> Martin >>> >>> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >>> >>>> Hi, >>>> >>>> The CDI spec defines a built-in bean for the type HttpServletRequest. In >>>> 3.8 it says: >>>> >>>> "A servlet container must provide the following built-in beans, all of >>>> which have qualifier @Default: >>>> >>>> a bean with bean type javax.servlet.http.HttpServletRequest, allowing >>>> injection of a reference to the HttpServletRequest" >>>> >>>> An HttpServletRequest however can be wrapped multiple times and by >>>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >>>> RequestDispatcher. >>>> >>>> The question now is; which version of the HttpServletRequest is supposed >>>> to be injected? >>>> >>>> * The first one in the chain? >>>> * The last one in the chain? >>>> * The current one at a given point in the chain? >>>> >>>> A little bit of experimenting seems to indicate it's now often "one of >>>> the first ones", e.g. the one that happened to be current when e.g. a >>>> ServletRequestListener that initialises a specific CDI implementation is >>>> called. >>>> >>>> I think this is a little confusing, as working with an injected request >>>> can now totally ignore the request wrapping that has been done and break >>>> an application badly. >>>> >>>> Thoughts? >>>> >>>> Kind regards, >>>> Arjan Tijms >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/license >>>> s/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/license >> s/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/20160908/5f565088/attachment.html From issues at jboss.org Thu Sep 8 07:43:01 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Thu, 8 Sep 2016 07:43:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290506#comment-13290506 ] Tomas Remes commented on CDI-220: --------------------------------- Just for record. Both options which should fail (session bean specializes managed bean and vice versa) have been tested for really long time:. See https://github.com/cdi-spec/cdi-tck/blob/1.1.0.Final/impl/src/main/java/org/jboss/cdi/tck/tests/inheritance/specialization/simple/broken/extendejb/SpecializingBeanExtendsEnterpriseBeanTest.java and https://github.com/cdi-spec/cdi-tck/blob/1.1.0.Final/impl/src/main/java/org/jboss/cdi/tck/tests/inheritance/specialization/enterprise/broken/extend/managedbean/DirectlyExtendsSimpleBeanTest.java > behaviour of CDI bean @Specializes session bean is undefined > ------------------------------------------------------------ > > Key: CDI-220 > URL: https://issues.jboss.org/browse/CDI-220 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.0, 1.1.EDR > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, F2F2016 > Fix For: 2.0 (discussion) > > > The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g. > @Stateless > public class Horse {..} > @ApplicationScoped @Specializes > public class Trakehner extends Horse {..} > Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error. > Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From rmannibucau at gmail.com Thu Sep 8 07:53:32 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 8 Sep 2016 13:53:32 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: AFAIK the server propagates by designt he request/response pair so even if there is a way to know which one it is at each moment you still have the issue you don't know what @Inject Request; means. @Inject @Web(FilterX.class) Request; is possible but not sure the real meaning and IMO it breaks the loose coupling of CDI so not sure it does worth to spec-ed it. Romain Manni-Bucau @rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | Tomitriber | JavaEE Factory 2016-09-08 13:31 GMT+02:00 arjan tijms : > Hi, > > On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau > wrote: > >> Hit that issue as well several times. >> >> It is more vicious than it looks like IMO cause CDI will *never* get >> *the* right request for everybody, it is as simple as that. Any part of the >> app can rely on the wrapper level N (of course N being different for each >> mentionned parts of the app). >> > > What I was thinking, but maybe I'm wrong, is that the application never > "just" wraps the request and uses it for itself. It always passes it to the > container, which then passes it on to the next Filter, Servlet, or > whatever. So at that point the container code has the opportunity to store > the request as being the "current" one. > > E.g. if you do: > > RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...); > dispatcher.forward(wrap(request), response); > > Then the RequestDispatcher, which is a container class, receives the > wrapped request and can make it available. > > The other way around, eventually every AuthModule, Filter or Servlet has > to be called by the container at some point. E.g. the "protected void > service(HttpServletRequest req, HttpServletResponse resp)" is called by the > container. > > So just before the container invokes the HttpServlet#service method, the > container can store the request, and CDI (via an SPI) can pick it up from > there. > > That way in every context you can always have the *current* request (the > request that's passed in to the last Servlet or Filter call on the stack). > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > > > >> Best CDI can do is to provide the request it has (already the case and >> cost pretty much nothing) and enable the user to produces very easily its >> own request from its filter (or equivalent) for its usage IMO - which is >> IMO already doable but maybe there is another shortcut we can introduce I >> didnt think about. If you look one step further any web framework built on >> top of CDI does it and therefore runs in a well known context. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Old Wordpress Blog >> | Github >> | LinkedIn >> | Tomitriber >> | JavaEE Factory >> >> >> 2016-09-08 13:03 GMT+02:00 arjan tijms : >> >>> Hi, >>> >>> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba wrote: >>> >>>> that's a good question. In Weld, the request object is captured during >>>> request context activation, i.e. during ServletRequestListener.requestInitialized() >>>> notification and before any filter or servlet is invoked. So wrappers are >>>> ignored and the original/first request is used. >>>> >>> >>> Indeed, although do note that some servers (Liberty and WebLogic I >>> think) send the ServletRequestListener.requestInitialized() >>> notification rather late, and do that after the application already has >>> seen the request and has had a chance to wrap it. This by itself is a >>> separate problem. So on these servers, Weld would receive an early request >>> but not necessarily the earliest. >>> >>> >>>> But TBH I don't think we can fix this easily as I'm not aware of any >>>> portable way to listen for "wrapping actions". >>>> >>> >>> This would have to happen with Server specific code I guess, just as >>> Weld now requires an SPI to obtain the current principal for injection. >>> >>> You could say that the Servlet container could store the request >>> "somewhere" on a stack structure, just before it invokes the >>> ServerAuthModule, Filter, Servlet and anything else I may have forgotten, >>> and then when control flows back to each Servlet, Filter, etc unwind that >>> stack. >>> >>> At the very least the spec for now should perhaps clarify this? >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>>> >>>> Martin >>>> >>>> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >>>> >>>>> Hi, >>>>> >>>>> The CDI spec defines a built-in bean for the type HttpServletRequest. >>>>> In >>>>> 3.8 it says: >>>>> >>>>> "A servlet container must provide the following built-in beans, all of >>>>> which have qualifier @Default: >>>>> >>>>> a bean with bean type javax.servlet.http.HttpServletRequest, allowing >>>>> injection of a reference to the HttpServletRequest" >>>>> >>>>> An HttpServletRequest however can be wrapped multiple times and by >>>>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >>>>> RequestDispatcher. >>>>> >>>>> The question now is; which version of the HttpServletRequest is >>>>> supposed >>>>> to be injected? >>>>> >>>>> * The first one in the chain? >>>>> * The last one in the chain? >>>>> * The current one at a given point in the chain? >>>>> >>>>> A little bit of experimenting seems to indicate it's now often "one of >>>>> the first ones", e.g. the one that happened to be current when e.g. a >>>>> ServletRequestListener that initialises a specific CDI implementation >>>>> is >>>>> called. >>>>> >>>>> I think this is a little confusing, as working with an injected request >>>>> can now totally ignore the request wrapping that has been done and >>>>> break >>>>> an application badly. >>>>> >>>>> Thoughts? >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/license >>> s/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/20160908/259e42d8/attachment-0001.html From arjan.tijms at gmail.com Thu Sep 8 08:10:22 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 8 Sep 2016 14:10:22 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Hi, I see what you mean. There's perhaps 2 solutions. 1. Specify @Inject HttpServletRequest to inject the current one (the top one from the stack) 2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, which is hopefully at least always the same for a given server), and introduce a qualifier @Current orso. I don't think you'd ever need @Inject @Web(FilterX.class) Request, which would mean searching back through the stack. If users would want that, they have to make their own producer. What we could do now is: AuthModule | | Filter1 (calls) ---> BeanX.foo() #1 | | Filter2 | | Servlet1 (calls) ---> BeanX.foo() #2 | | (forward) ---> Servlet2 (calls) ---> BeanX.foo() #3 If BeanX is injected with @Inject HttpServletRequest or @Inject @Current HttpServletRequest, then: In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to Filter1 In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet1 In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet2 Since the request processing is strictly sequential here, a given thread always has the concept of the request that was passed it to the module/filter/servlet that's highest up the call stack. That one would IMHO be the most logical one that you want to work with. Kind regards, Arjan Tijms On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau wrote: > AFAIK the server propagates by designt he request/response pair so even if > there is a way to know which one it is at each moment you still have the > issue you don't know what @Inject Request; means. @Inject > @Web(FilterX.class) Request; is possible but not sure the real meaning and > IMO it breaks the loose coupling of CDI so not sure it does worth to > spec-ed it. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Wordpress Blog > | Github > | LinkedIn > | Tomitriber > | JavaEE Factory > > > 2016-09-08 13:31 GMT+02:00 arjan tijms : > >> Hi, >> >> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau > > wrote: >> >>> Hit that issue as well several times. >>> >>> It is more vicious than it looks like IMO cause CDI will *never* get >>> *the* right request for everybody, it is as simple as that. Any part of the >>> app can rely on the wrapper level N (of course N being different for each >>> mentionned parts of the app). >>> >> >> What I was thinking, but maybe I'm wrong, is that the application never >> "just" wraps the request and uses it for itself. It always passes it to the >> container, which then passes it on to the next Filter, Servlet, or >> whatever. So at that point the container code has the opportunity to store >> the request as being the "current" one. >> >> E.g. if you do: >> >> RequestDispatcher dispatcher = servletContext().getRequestDis >> patcher(...); >> dispatcher.forward(wrap(request), response); >> >> Then the RequestDispatcher, which is a container class, receives the >> wrapped request and can make it available. >> >> The other way around, eventually every AuthModule, Filter or Servlet has >> to be called by the container at some point. E.g. the "protected void >> service(HttpServletRequest req, HttpServletResponse resp)" is called by the >> container. >> >> So just before the container invokes the HttpServlet#service method, the >> container can store the request, and CDI (via an SPI) can pick it up from >> there. >> >> That way in every context you can always have the *current* request (the >> request that's passed in to the last Servlet or Filter call on the stack). >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> Best CDI can do is to provide the request it has (already the case and >>> cost pretty much nothing) and enable the user to produces very easily its >>> own request from its filter (or equivalent) for its usage IMO - which is >>> IMO already doable but maybe there is another shortcut we can introduce I >>> didnt think about. If you look one step further any web framework built on >>> top of CDI does it and therefore runs in a well known context. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Old Wordpress Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> | JavaEE Factory >>> >>> >>> 2016-09-08 13:03 GMT+02:00 arjan tijms : >>> >>>> Hi, >>>> >>>> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >>>> wrote: >>>> >>>>> that's a good question. In Weld, the request object is captured during >>>>> request context activation, i.e. during ServletRequestListener.requestInitialized() >>>>> notification and before any filter or servlet is invoked. So wrappers are >>>>> ignored and the original/first request is used. >>>>> >>>> >>>> Indeed, although do note that some servers (Liberty and WebLogic I >>>> think) send the ServletRequestListener.requestInitialized() >>>> notification rather late, and do that after the application already has >>>> seen the request and has had a chance to wrap it. This by itself is a >>>> separate problem. So on these servers, Weld would receive an early request >>>> but not necessarily the earliest. >>>> >>>> >>>>> But TBH I don't think we can fix this easily as I'm not aware of any >>>>> portable way to listen for "wrapping actions". >>>>> >>>> >>>> This would have to happen with Server specific code I guess, just as >>>> Weld now requires an SPI to obtain the current principal for injection. >>>> >>>> You could say that the Servlet container could store the request >>>> "somewhere" on a stack structure, just before it invokes the >>>> ServerAuthModule, Filter, Servlet and anything else I may have forgotten, >>>> and then when control flows back to each Servlet, Filter, etc unwind that >>>> stack. >>>> >>>> At the very least the spec for now should perhaps clarify this? >>>> >>>> Kind regards, >>>> Arjan Tijms >>>> >>>> >>>> >>>> >>>>> >>>>> Martin >>>>> >>>>> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >>>>> >>>>>> Hi, >>>>>> >>>>>> The CDI spec defines a built-in bean for the type HttpServletRequest. >>>>>> In >>>>>> 3.8 it says: >>>>>> >>>>>> "A servlet container must provide the following built-in beans, all of >>>>>> which have qualifier @Default: >>>>>> >>>>>> a bean with bean type javax.servlet.http.HttpServletRequest, allowing >>>>>> injection of a reference to the HttpServletRequest" >>>>>> >>>>>> An HttpServletRequest however can be wrapped multiple times and by >>>>>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >>>>>> RequestDispatcher. >>>>>> >>>>>> The question now is; which version of the HttpServletRequest is >>>>>> supposed >>>>>> to be injected? >>>>>> >>>>>> * The first one in the chain? >>>>>> * The last one in the chain? >>>>>> * The current one at a given point in the chain? >>>>>> >>>>>> A little bit of experimenting seems to indicate it's now often "one of >>>>>> the first ones", e.g. the one that happened to be current when e.g. a >>>>>> ServletRequestListener that initialises a specific CDI implementation >>>>>> is >>>>>> called. >>>>>> >>>>>> I think this is a little confusing, as working with an injected >>>>>> request >>>>>> can now totally ignore the request wrapping that has been done and >>>>>> break >>>>>> an application badly. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Kind regards, >>>>>> Arjan Tijms >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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/license >>>> s/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/20160908/2c1b9099/attachment.html From rmannibucau at gmail.com Thu Sep 8 08:14:00 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 8 Sep 2016 14:14:00 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Well supposes @Current means something for the component getting the injection, I can see where you go starting from AuthModule but more your browse the chain less it makes sense IMO -> maybe something to work on auth side more than CDI? That said CDI has a notion for conversions which is to define a provided filter. Maybe that's the easiest here: a user could define one or multiple filters ("CDI Filter" or whatever name) which would set CDI position in the filter chain, defining it N times would update "current" request and the produces one so we keep current default and enable the user to control it himself finely when needed. Romain Manni-Bucau @rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | Tomitriber | JavaEE Factory 2016-09-08 14:10 GMT+02:00 arjan tijms : > Hi, > > I see what you mean. > > There's perhaps 2 solutions. > > 1. Specify @Inject HttpServletRequest to inject the current one (the top > one from the stack) > 2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, > which is hopefully at least always the same for a given server), and > introduce a qualifier @Current orso. > > I don't think you'd ever need @Inject @Web(FilterX.class) Request, which > would mean searching back through the stack. If users would want that, they > have to make their own producer. > > What we could do now is: > > AuthModule > | > | > Filter1 (calls) ---> BeanX.foo() #1 > | > | > Filter2 > | > | > Servlet1 (calls) ---> BeanX.foo() #2 > | > | > (forward) ---> Servlet2 (calls) ---> BeanX.foo() #3 > > > > If BeanX is injected with @Inject HttpServletRequest or @Inject @Current HttpServletRequest, > then: > > > In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to > Filter1 > > In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to > Servlet1 > > In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to > Servlet2 > > > > Since the request processing is strictly sequential here, a given thread > always has the concept of the request that was passed it to the > module/filter/servlet that's highest up the call stack. That one would IMHO > be the most logical one that you want to work with. > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau > wrote: > >> AFAIK the server propagates by designt he request/response pair so even >> if there is a way to know which one it is at each moment you still have the >> issue you don't know what @Inject Request; means. @Inject >> @Web(FilterX.class) Request; is possible but not sure the real meaning and >> IMO it breaks the loose coupling of CDI so not sure it does worth to >> spec-ed it. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Old Wordpress Blog >> | Github >> | LinkedIn >> | Tomitriber >> | JavaEE Factory >> >> >> 2016-09-08 13:31 GMT+02:00 arjan tijms : >> >>> Hi, >>> >>> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> Hit that issue as well several times. >>>> >>>> It is more vicious than it looks like IMO cause CDI will *never* get >>>> *the* right request for everybody, it is as simple as that. Any part of the >>>> app can rely on the wrapper level N (of course N being different for each >>>> mentionned parts of the app). >>>> >>> >>> What I was thinking, but maybe I'm wrong, is that the application never >>> "just" wraps the request and uses it for itself. It always passes it to the >>> container, which then passes it on to the next Filter, Servlet, or >>> whatever. So at that point the container code has the opportunity to store >>> the request as being the "current" one. >>> >>> E.g. if you do: >>> >>> RequestDispatcher dispatcher = servletContext().getRequestDis >>> patcher(...); >>> dispatcher.forward(wrap(request), response); >>> >>> Then the RequestDispatcher, which is a container class, receives the >>> wrapped request and can make it available. >>> >>> The other way around, eventually every AuthModule, Filter or Servlet has >>> to be called by the container at some point. E.g. the "protected void >>> service(HttpServletRequest req, HttpServletResponse resp)" is called by the >>> container. >>> >>> So just before the container invokes the HttpServlet#service method, the >>> container can store the request, and CDI (via an SPI) can pick it up from >>> there. >>> >>> That way in every context you can always have the *current* request (the >>> request that's passed in to the last Servlet or Filter call on the stack). >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> Best CDI can do is to provide the request it has (already the case and >>>> cost pretty much nothing) and enable the user to produces very easily its >>>> own request from its filter (or equivalent) for its usage IMO - which is >>>> IMO already doable but maybe there is another shortcut we can introduce I >>>> didnt think about. If you look one step further any web framework built on >>>> top of CDI does it and therefore runs in a well known context. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Old Wordpress Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> | JavaEE Factory >>>> >>>> >>>> 2016-09-08 13:03 GMT+02:00 arjan tijms : >>>> >>>>> Hi, >>>>> >>>>> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >>>>> wrote: >>>>> >>>>>> that's a good question. In Weld, the request object is captured >>>>>> during request context activation, i.e. during >>>>>> ServletRequestListener.requestInitialized() notification and before >>>>>> any filter or servlet is invoked. So wrappers are ignored and the >>>>>> original/first request is used. >>>>>> >>>>> >>>>> Indeed, although do note that some servers (Liberty and WebLogic I >>>>> think) send the ServletRequestListener.requestInitialized() >>>>> notification rather late, and do that after the application already has >>>>> seen the request and has had a chance to wrap it. This by itself is a >>>>> separate problem. So on these servers, Weld would receive an early request >>>>> but not necessarily the earliest. >>>>> >>>>> >>>>>> But TBH I don't think we can fix this easily as I'm not aware of any >>>>>> portable way to listen for "wrapping actions". >>>>>> >>>>> >>>>> This would have to happen with Server specific code I guess, just as >>>>> Weld now requires an SPI to obtain the current principal for injection. >>>>> >>>>> You could say that the Servlet container could store the request >>>>> "somewhere" on a stack structure, just before it invokes the >>>>> ServerAuthModule, Filter, Servlet and anything else I may have forgotten, >>>>> and then when control flows back to each Servlet, Filter, etc unwind that >>>>> stack. >>>>> >>>>> At the very least the spec for now should perhaps clarify this? >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Martin >>>>>> >>>>>> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The CDI spec defines a built-in bean for the type >>>>>>> HttpServletRequest. In >>>>>>> 3.8 it says: >>>>>>> >>>>>>> "A servlet container must provide the following built-in beans, all >>>>>>> of >>>>>>> which have qualifier @Default: >>>>>>> >>>>>>> a bean with bean type javax.servlet.http.HttpServletRequest, >>>>>>> allowing >>>>>>> injection of a reference to the HttpServletRequest" >>>>>>> >>>>>>> An HttpServletRequest however can be wrapped multiple times and by >>>>>>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >>>>>>> RequestDispatcher. >>>>>>> >>>>>>> The question now is; which version of the HttpServletRequest is >>>>>>> supposed >>>>>>> to be injected? >>>>>>> >>>>>>> * The first one in the chain? >>>>>>> * The last one in the chain? >>>>>>> * The current one at a given point in the chain? >>>>>>> >>>>>>> A little bit of experimenting seems to indicate it's now often "one >>>>>>> of >>>>>>> the first ones", e.g. the one that happened to be current when e.g. a >>>>>>> ServletRequestListener that initialises a specific CDI >>>>>>> implementation is >>>>>>> called. >>>>>>> >>>>>>> I think this is a little confusing, as working with an injected >>>>>>> request >>>>>>> can now totally ignore the request wrapping that has been done and >>>>>>> break >>>>>>> an application badly. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan Tijms >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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/20160908/9bd09288/attachment-0001.html From mkouba at redhat.com Thu Sep 8 08:14:37 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 8 Sep 2016 14:14:37 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: The best solution might be to let the servlet container provide the beans for all the servlet artifacts (HttpServletRequest, HttpSession and ServletContext). But it's more complicated then it sounds. For example, HttpServletRequest attibutes might be used as backing storage of the request context. So that it cannot simply change... Anyway, I think this problem deserves some attention from both the CDI and the Servlet EG. Martin Dne 8.9.2016 v 13:31 arjan tijms napsal(a): > Hi, > > On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau > > wrote: > > Hit that issue as well several times. > > It is more vicious than it looks like IMO cause CDI will *never* get > *the* right request for everybody, it is as simple as that. Any part > of the app can rely on the wrapper level N (of course N being > different for each mentionned parts of the app). > > > What I was thinking, but maybe I'm wrong, is that the application never > "just" wraps the request and uses it for itself. It always passes it to > the container, which then passes it on to the next Filter, Servlet, or > whatever. So at that point the container code has the opportunity to > store the request as being the "current" one. > > E.g. if you do: > > RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...); > dispatcher.forward(wrap(request), response); > > Then the RequestDispatcher, which is a container class, receives the > wrapped request and can make it available. > > The other way around, eventually every AuthModule, Filter or Servlet has > to be called by the container at some point. E.g. the "protected void > service(HttpServletRequest req, HttpServletResponse resp)" is called by > the container. > > So just before the container invokes the HttpServlet#service method, the > container can store the request, and CDI (via an SPI) can pick it up > from there. > > That way in every context you can always have the *current* request (the > request that's passed in to the last Servlet or Filter call on the stack). > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > > > > Best CDI can do is to provide the request it has (already the case > and cost pretty much nothing) and enable the user to produces very > easily its own request from its filter (or equivalent) for its usage > IMO - which is IMO already doable but maybe there is another > shortcut we can introduce I didnt think about. If you look one step > further any web framework built on top of CDI does it and therefore > runs in a well known context. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Wordpress Blog > | Github > | LinkedIn > | Tomitriber > | JavaEE Factory > > > 2016-09-08 13:03 GMT+02:00 arjan tijms >: > > Hi, > > On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba > wrote: > > that's a good question. In Weld, the request object is > captured during request context activation, i.e. during > ServletRequestListener.requestInitialized() notification and > before any filter or servlet is invoked. So wrappers are > ignored and the original/first request is used. > > > Indeed, although do note that some servers (Liberty and WebLogic > I think) send the ServletRequestListener.requestInitialized() > notification rather late, and do that after the application > already has seen the request and has had a chance to wrap it. > This by itself is a separate problem. So on these servers, Weld > would receive an early request but not necessarily the earliest. > > > But TBH I don't think we can fix this easily as I'm not > aware of any portable way to listen for "wrapping actions". > > > This would have to happen with Server specific code I guess, > just as Weld now requires an SPI to obtain the current principal > for injection. > > You could say that the Servlet container could store the request > "somewhere" on a stack structure, just before it invokes the > ServerAuthModule, Filter, Servlet and anything else I may have > forgotten, and then when control flows back to each Servlet, > Filter, etc unwind that stack. > > At the very least the spec for now should perhaps clarify this? > > Kind regards, > Arjan Tijms > > > > > > Martin > > Dne 8.9.2016 v 11:02 arjan tijms napsal(a): > > Hi, > > The CDI spec defines a built-in bean for the type > HttpServletRequest. In > 3.8 it says: > > "A servlet container must provide the following built-in > beans, all of > which have qualifier @Default: > > a bean with bean type > javax.servlet.http.HttpServletRequest, allowing > injection of a reference to the HttpServletRequest" > > An HttpServletRequest however can be wrapped multiple > times and by > multiple artefacts. I.e. by a ServerAuthModule, Filter and a > RequestDispatcher. > > The question now is; which version of the > HttpServletRequest is supposed > to be injected? > > * The first one in the chain? > * The last one in the chain? > * The current one at a given point in the chain? > > A little bit of experimenting seems to indicate it's now > often "one of > the first ones", e.g. the one that happened to be > current when e.g. a > ServletRequestListener that initialises a specific CDI > implementation is > called. > > I think this is a little confusing, as working with an > injected request > can now totally ignore the request wrapping that has > been done and break > an application badly. > > Thoughts? > > Kind regards, > Arjan Tijms > > > > _______________________________________________ > 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. > > > From arjan.tijms at gmail.com Thu Sep 8 08:21:56 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 8 Sep 2016 14:21:56 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Hi, Sorry, forget the AuthModule for now ;) I just put it there because it's often forgotten that it also gets to see the request and can wrap it, but for a change (I know, it's rare with me ;)) the issue here is primarily unrelated to auth. Kind regards, Arjan Tijms On Thu, Sep 8, 2016 at 2:14 PM, Romain Manni-Bucau wrote: > Well supposes @Current means something for the component getting the > injection, I can see where you go starting from AuthModule but more your > browse the chain less it makes sense IMO -> maybe something to work on auth > side more than CDI? > > That said CDI has a notion for conversions which is to define a provided > filter. Maybe that's the easiest here: a user could define one or multiple > filters ("CDI Filter" or whatever name) which would set CDI position in the > filter chain, defining it N times would update "current" request and the > produces one so we keep current default and enable the user to control it > himself finely when needed. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Wordpress Blog > | Github > | LinkedIn > | Tomitriber > | JavaEE Factory > > > 2016-09-08 14:10 GMT+02:00 arjan tijms : > >> Hi, >> >> I see what you mean. >> >> There's perhaps 2 solutions. >> >> 1. Specify @Inject HttpServletRequest to inject the current one (the top >> one from the stack) >> 2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, >> which is hopefully at least always the same for a given server), and >> introduce a qualifier @Current orso. >> >> I don't think you'd ever need @Inject @Web(FilterX.class) Request, which >> would mean searching back through the stack. If users would want that, they >> have to make their own producer. >> >> What we could do now is: >> >> AuthModule >> | >> | >> Filter1 (calls) ---> BeanX.foo() #1 >> | >> | >> Filter2 >> | >> | >> Servlet1 (calls) ---> BeanX.foo() #2 >> | >> | >> (forward) ---> Servlet2 (calls) ---> BeanX.foo() #3 >> >> >> >> If BeanX is injected with @Inject HttpServletRequest or >> @Inject @Current HttpServletRequest, then: >> >> >> In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to >> Filter1 >> >> In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to >> Servlet1 >> >> In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to >> Servlet2 >> >> >> >> Since the request processing is strictly sequential here, a given thread >> always has the concept of the request that was passed it to the >> module/filter/servlet that's highest up the call stack. That one would IMHO >> be the most logical one that you want to work with. >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau > > wrote: >> >>> AFAIK the server propagates by designt he request/response pair so even >>> if there is a way to know which one it is at each moment you still have the >>> issue you don't know what @Inject Request; means. @Inject >>> @Web(FilterX.class) Request; is possible but not sure the real meaning and >>> IMO it breaks the loose coupling of CDI so not sure it does worth to >>> spec-ed it. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Old Wordpress Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> | JavaEE Factory >>> >>> >>> 2016-09-08 13:31 GMT+02:00 arjan tijms : >>> >>>> Hi, >>>> >>>> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau < >>>> rmannibucau at gmail.com> wrote: >>>> >>>>> Hit that issue as well several times. >>>>> >>>>> It is more vicious than it looks like IMO cause CDI will *never* get >>>>> *the* right request for everybody, it is as simple as that. Any part of the >>>>> app can rely on the wrapper level N (of course N being different for each >>>>> mentionned parts of the app). >>>>> >>>> >>>> What I was thinking, but maybe I'm wrong, is that the application never >>>> "just" wraps the request and uses it for itself. It always passes it to the >>>> container, which then passes it on to the next Filter, Servlet, or >>>> whatever. So at that point the container code has the opportunity to store >>>> the request as being the "current" one. >>>> >>>> E.g. if you do: >>>> >>>> RequestDispatcher dispatcher = servletContext().getRequestDis >>>> patcher(...); >>>> dispatcher.forward(wrap(request), response); >>>> >>>> Then the RequestDispatcher, which is a container class, receives the >>>> wrapped request and can make it available. >>>> >>>> The other way around, eventually every AuthModule, Filter or Servlet >>>> has to be called by the container at some point. E.g. the "protected void >>>> service(HttpServletRequest req, HttpServletResponse resp)" is called by the >>>> container. >>>> >>>> So just before the container invokes the HttpServlet#service method, >>>> the container can store the request, and CDI (via an SPI) can pick it up >>>> from there. >>>> >>>> That way in every context you can always have the *current* request >>>> (the request that's passed in to the last Servlet or Filter call on the >>>> stack). >>>> >>>> Kind regards, >>>> Arjan Tijms >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Best CDI can do is to provide the request it has (already the case and >>>>> cost pretty much nothing) and enable the user to produces very easily its >>>>> own request from its filter (or equivalent) for its usage IMO - which is >>>>> IMO already doable but maybe there is another shortcut we can introduce I >>>>> didnt think about. If you look one step further any web framework built on >>>>> top of CDI does it and therefore runs in a well known context. >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog >>>>> | Old Wordpress Blog >>>>> | Github >>>>> | LinkedIn >>>>> | Tomitriber >>>>> | JavaEE Factory >>>>> >>>>> >>>>> 2016-09-08 13:03 GMT+02:00 arjan tijms : >>>>> >>>>>> Hi, >>>>>> >>>>>> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >>>>>> wrote: >>>>>> >>>>>>> that's a good question. In Weld, the request object is captured >>>>>>> during request context activation, i.e. during >>>>>>> ServletRequestListener.requestInitialized() notification and before >>>>>>> any filter or servlet is invoked. So wrappers are ignored and the >>>>>>> original/first request is used. >>>>>>> >>>>>> >>>>>> Indeed, although do note that some servers (Liberty and WebLogic I >>>>>> think) send the ServletRequestListener.requestInitialized() >>>>>> notification rather late, and do that after the application already has >>>>>> seen the request and has had a chance to wrap it. This by itself is a >>>>>> separate problem. So on these servers, Weld would receive an early request >>>>>> but not necessarily the earliest. >>>>>> >>>>>> >>>>>>> But TBH I don't think we can fix this easily as I'm not aware of any >>>>>>> portable way to listen for "wrapping actions". >>>>>>> >>>>>> >>>>>> This would have to happen with Server specific code I guess, just as >>>>>> Weld now requires an SPI to obtain the current principal for injection. >>>>>> >>>>>> You could say that the Servlet container could store the request >>>>>> "somewhere" on a stack structure, just before it invokes the >>>>>> ServerAuthModule, Filter, Servlet and anything else I may have forgotten, >>>>>> and then when control flows back to each Servlet, Filter, etc unwind that >>>>>> stack. >>>>>> >>>>>> At the very least the spec for now should perhaps clarify this? >>>>>> >>>>>> Kind regards, >>>>>> Arjan Tijms >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> The CDI spec defines a built-in bean for the type >>>>>>>> HttpServletRequest. In >>>>>>>> 3.8 it says: >>>>>>>> >>>>>>>> "A servlet container must provide the following built-in beans, all >>>>>>>> of >>>>>>>> which have qualifier @Default: >>>>>>>> >>>>>>>> a bean with bean type javax.servlet.http.HttpServletRequest, >>>>>>>> allowing >>>>>>>> injection of a reference to the HttpServletRequest" >>>>>>>> >>>>>>>> An HttpServletRequest however can be wrapped multiple times and by >>>>>>>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >>>>>>>> RequestDispatcher. >>>>>>>> >>>>>>>> The question now is; which version of the HttpServletRequest is >>>>>>>> supposed >>>>>>>> to be injected? >>>>>>>> >>>>>>>> * The first one in the chain? >>>>>>>> * The last one in the chain? >>>>>>>> * The current one at a given point in the chain? >>>>>>>> >>>>>>>> A little bit of experimenting seems to indicate it's now often "one >>>>>>>> of >>>>>>>> the first ones", e.g. the one that happened to be current when e.g. >>>>>>>> a >>>>>>>> ServletRequestListener that initialises a specific CDI >>>>>>>> implementation is >>>>>>>> called. >>>>>>>> >>>>>>>> I think this is a little confusing, as working with an injected >>>>>>>> request >>>>>>>> can now totally ignore the request wrapping that has been done and >>>>>>>> break >>>>>>>> an application badly. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Arjan Tijms >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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/20160908/32f74a4b/attachment-0001.html From arjan.tijms at gmail.com Thu Sep 8 08:28:56 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 8 Sep 2016 14:28:56 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Hi, On Thu, Sep 8, 2016 at 2:14 PM, Martin Kouba wrote: > The best solution might be to let the servlet container provide the beans > for all the servlet artifacts (HttpServletRequest, HttpSession and > ServletContext). > +100 for that. Several issues were already created for that in the past, but to my understanding it was misunderstood by some in the Servlet EG and subsequently closed. See https://java.net/jira/browse/SERVLET_SPEC-116 Specifically this comment was a little problematic: GW> More over, GW> I'm concerned that by making CDI to servlet mapping a responsibility GW> of the servlet container, then we are going to have to do a GW> container to CDI adaptation for every CDI implementation out there. I think this is missing the key insight that CDI extensions are portable and that it's "just" providing a 1 class extension that adds 3 orso build-in beans. Kind regards, Arjan Tijms > > But it's more complicated then it sounds. For example, HttpServletRequest > attibutes might be used as backing storage of the request context. So that > it cannot simply change... > > Anyway, I think this problem deserves some attention from both the CDI and > the Servlet EG. > > Martin > > Dne 8.9.2016 v 13:31 arjan tijms napsal(a): > >> Hi, >> >> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau >> > wrote: >> >> Hit that issue as well several times. >> >> It is more vicious than it looks like IMO cause CDI will *never* get >> *the* right request for everybody, it is as simple as that. Any part >> of the app can rely on the wrapper level N (of course N being >> different for each mentionned parts of the app). >> >> >> What I was thinking, but maybe I'm wrong, is that the application never >> "just" wraps the request and uses it for itself. It always passes it to >> the container, which then passes it on to the next Filter, Servlet, or >> whatever. So at that point the container code has the opportunity to >> store the request as being the "current" one. >> >> E.g. if you do: >> >> RequestDispatcher dispatcher = servletContext().getRequestDis >> patcher(...); >> dispatcher.forward(wrap(request), response); >> >> Then the RequestDispatcher, which is a container class, receives the >> wrapped request and can make it available. >> >> The other way around, eventually every AuthModule, Filter or Servlet has >> to be called by the container at some point. E.g. the "protected void >> service(HttpServletRequest req, HttpServletResponse resp)" is called by >> the container. >> >> So just before the container invokes the HttpServlet#service method, the >> container can store the request, and CDI (via an SPI) can pick it up >> from there. >> >> That way in every context you can always have the *current* request (the >> request that's passed in to the last Servlet or Filter call on the stack). >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best CDI can do is to provide the request it has (already the case >> and cost pretty much nothing) and enable the user to produces very >> easily its own request from its filter (or equivalent) for its usage >> IMO - which is IMO already doable but maybe there is another >> shortcut we can introduce I didnt think about. If you look one step >> further any web framework built on top of CDI does it and therefore >> runs in a well known context. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Old Wordpress Blog >> | Github >> | LinkedIn >> | Tomitriber >> | JavaEE Factory >> >> >> 2016-09-08 13:03 GMT+02:00 arjan tijms > >: >> >> Hi, >> >> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba > > wrote: >> >> that's a good question. In Weld, the request object is >> captured during request context activation, i.e. during >> ServletRequestListener.requestInitialized() notification and >> before any filter or servlet is invoked. So wrappers are >> ignored and the original/first request is used. >> >> >> Indeed, although do note that some servers (Liberty and WebLogic >> I think) send the ServletRequestListener.requestInitialized() >> notification rather late, and do that after the application >> already has seen the request and has had a chance to wrap it. >> This by itself is a separate problem. So on these servers, Weld >> would receive an early request but not necessarily the earliest. >> >> >> But TBH I don't think we can fix this easily as I'm not >> aware of any portable way to listen for "wrapping actions". >> >> >> This would have to happen with Server specific code I guess, >> just as Weld now requires an SPI to obtain the current principal >> for injection. >> >> You could say that the Servlet container could store the request >> "somewhere" on a stack structure, just before it invokes the >> ServerAuthModule, Filter, Servlet and anything else I may have >> forgotten, and then when control flows back to each Servlet, >> Filter, etc unwind that stack. >> >> At the very least the spec for now should perhaps clarify this? >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> Martin >> >> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >> >> Hi, >> >> The CDI spec defines a built-in bean for the type >> HttpServletRequest. In >> 3.8 it says: >> >> "A servlet container must provide the following built-in >> beans, all of >> which have qualifier @Default: >> >> a bean with bean type >> javax.servlet.http.HttpServletRequest, allowing >> injection of a reference to the HttpServletRequest" >> >> An HttpServletRequest however can be wrapped multiple >> times and by >> multiple artefacts. I.e. by a ServerAuthModule, Filter >> and a >> RequestDispatcher. >> >> The question now is; which version of the >> HttpServletRequest is supposed >> to be injected? >> >> * The first one in the chain? >> * The last one in the chain? >> * The current one at a given point in the chain? >> >> A little bit of experimenting seems to indicate it's now >> often "one of >> the first ones", e.g. the one that happened to be >> current when e.g. a >> ServletRequestListener that initialises a specific CDI >> implementation is >> called. >> >> I think this is a little confusing, as working with an >> injected request >> can now totally ignore the request wrapping that has >> been done and break >> an application badly. >> >> Thoughts? >> >> Kind regards, >> Arjan Tijms >> >> >> >> _______________________________________________ >> 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/20160908/73da1074/attachment.html From rmannibucau at gmail.com Thu Sep 8 08:28:59 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 8 Sep 2016 14:28:59 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: 2016-09-08 14:21 GMT+02:00 arjan tijms : > Hi, > > Sorry, forget the AuthModule for now ;) I just put it there because it's > often forgotten that it also gets to see the request and can wrap it, but > for a change (I know, it's rare with me ;)) the issue here is primarily > unrelated to auth. > > ok, was not clear: point with AuthModule is it is not required to be in the servlet chain at all (can be before), that's why i pointed out it was maybe another topic and a small missing integration between 2 specs. > Kind regards, > Arjan Tijms > > > > On Thu, Sep 8, 2016 at 2:14 PM, Romain Manni-Bucau > wrote: > >> Well supposes @Current means something for the component getting the >> injection, I can see where you go starting from AuthModule but more your >> browse the chain less it makes sense IMO -> maybe something to work on auth >> side more than CDI? >> >> That said CDI has a notion for conversions which is to define a provided >> filter. Maybe that's the easiest here: a user could define one or multiple >> filters ("CDI Filter" or whatever name) which would set CDI position in the >> filter chain, defining it N times would update "current" request and the >> produces one so we keep current default and enable the user to control it >> himself finely when needed. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Old Wordpress Blog >> | Github >> | LinkedIn >> | Tomitriber >> | JavaEE Factory >> >> >> 2016-09-08 14:10 GMT+02:00 arjan tijms : >> >>> Hi, >>> >>> I see what you mean. >>> >>> There's perhaps 2 solutions. >>> >>> 1. Specify @Inject HttpServletRequest to inject the current one (the top >>> one from the stack) >>> 2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one, >>> which is hopefully at least always the same for a given server), and >>> introduce a qualifier @Current orso. >>> >>> I don't think you'd ever need @Inject @Web(FilterX.class) Request, >>> which would mean searching back through the stack. If users would want >>> that, they have to make their own producer. >>> >>> What we could do now is: >>> >>> AuthModule >>> | >>> | >>> Filter1 (calls) ---> BeanX.foo() #1 >>> | >>> | >>> Filter2 >>> | >>> | >>> Servlet1 (calls) ---> BeanX.foo() #2 >>> | >>> | >>> (forward) ---> Servlet2 (calls) ---> BeanX.foo() #3 >>> >>> >>> >>> If BeanX is injected with @Inject HttpServletRequest or >>> @Inject @Current HttpServletRequest, then: >>> >>> >>> In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to >>> Filter1 >>> >>> In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to >>> Servlet1 >>> >>> In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to >>> Servlet2 >>> >>> >>> >>> Since the request processing is strictly sequential here, a given thread >>> always has the concept of the request that was passed it to the >>> module/filter/servlet that's highest up the call stack. That one would IMHO >>> be the most logical one that you want to work with. >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau < >>> rmannibucau at gmail.com> wrote: >>> >>>> AFAIK the server propagates by designt he request/response pair so even >>>> if there is a way to know which one it is at each moment you still have the >>>> issue you don't know what @Inject Request; means. @Inject >>>> @Web(FilterX.class) Request; is possible but not sure the real meaning and >>>> IMO it breaks the loose coupling of CDI so not sure it does worth to >>>> spec-ed it. >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog >>>> | Old Wordpress Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> | JavaEE Factory >>>> >>>> >>>> 2016-09-08 13:31 GMT+02:00 arjan tijms : >>>> >>>>> Hi, >>>>> >>>>> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau < >>>>> rmannibucau at gmail.com> wrote: >>>>> >>>>>> Hit that issue as well several times. >>>>>> >>>>>> It is more vicious than it looks like IMO cause CDI will *never* get >>>>>> *the* right request for everybody, it is as simple as that. Any part of the >>>>>> app can rely on the wrapper level N (of course N being different for each >>>>>> mentionned parts of the app). >>>>>> >>>>> >>>>> What I was thinking, but maybe I'm wrong, is that the application >>>>> never "just" wraps the request and uses it for itself. It always passes it >>>>> to the container, which then passes it on to the next Filter, Servlet, or >>>>> whatever. So at that point the container code has the opportunity to store >>>>> the request as being the "current" one. >>>>> >>>>> E.g. if you do: >>>>> >>>>> RequestDispatcher dispatcher = servletContext().getRequestDis >>>>> patcher(...); >>>>> dispatcher.forward(wrap(request), response); >>>>> >>>>> Then the RequestDispatcher, which is a container class, receives the >>>>> wrapped request and can make it available. >>>>> >>>>> The other way around, eventually every AuthModule, Filter or Servlet >>>>> has to be called by the container at some point. E.g. the "protected void >>>>> service(HttpServletRequest req, HttpServletResponse resp)" is called by the >>>>> container. >>>>> >>>>> So just before the container invokes the HttpServlet#service method, >>>>> the container can store the request, and CDI (via an SPI) can pick it up >>>>> from there. >>>>> >>>>> That way in every context you can always have the *current* request >>>>> (the request that's passed in to the last Servlet or Filter call on the >>>>> stack). >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Best CDI can do is to provide the request it has (already the case >>>>>> and cost pretty much nothing) and enable the user to produces very easily >>>>>> its own request from its filter (or equivalent) for its usage IMO - which >>>>>> is IMO already doable but maybe there is another shortcut we can introduce >>>>>> I didnt think about. If you look one step further any web framework built >>>>>> on top of CDI does it and therefore runs in a well known context. >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau | Blog >>>>>> | Old Wordpress Blog >>>>>> | Github >>>>>> | LinkedIn >>>>>> | Tomitriber >>>>>> | JavaEE Factory >>>>>> >>>>>> >>>>>> 2016-09-08 13:03 GMT+02:00 arjan tijms : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >>>>>>> wrote: >>>>>>> >>>>>>>> that's a good question. In Weld, the request object is captured >>>>>>>> during request context activation, i.e. during >>>>>>>> ServletRequestListener.requestInitialized() notification and >>>>>>>> before any filter or servlet is invoked. So wrappers are ignored and the >>>>>>>> original/first request is used. >>>>>>>> >>>>>>> >>>>>>> Indeed, although do note that some servers (Liberty and WebLogic I >>>>>>> think) send the ServletRequestListener.requestInitialized() >>>>>>> notification rather late, and do that after the application already has >>>>>>> seen the request and has had a chance to wrap it. This by itself is a >>>>>>> separate problem. So on these servers, Weld would receive an early request >>>>>>> but not necessarily the earliest. >>>>>>> >>>>>>> >>>>>>>> But TBH I don't think we can fix this easily as I'm not aware of >>>>>>>> any portable way to listen for "wrapping actions". >>>>>>>> >>>>>>> >>>>>>> This would have to happen with Server specific code I guess, just as >>>>>>> Weld now requires an SPI to obtain the current principal for injection. >>>>>>> >>>>>>> You could say that the Servlet container could store the request >>>>>>> "somewhere" on a stack structure, just before it invokes the >>>>>>> ServerAuthModule, Filter, Servlet and anything else I may have forgotten, >>>>>>> and then when control flows back to each Servlet, Filter, etc unwind that >>>>>>> stack. >>>>>>> >>>>>>> At the very least the spec for now should perhaps clarify this? >>>>>>> >>>>>>> Kind regards, >>>>>>> Arjan Tijms >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The CDI spec defines a built-in bean for the type >>>>>>>>> HttpServletRequest. In >>>>>>>>> 3.8 it says: >>>>>>>>> >>>>>>>>> "A servlet container must provide the following built-in beans, >>>>>>>>> all of >>>>>>>>> which have qualifier @Default: >>>>>>>>> >>>>>>>>> a bean with bean type javax.servlet.http.HttpServletRequest, >>>>>>>>> allowing >>>>>>>>> injection of a reference to the HttpServletRequest" >>>>>>>>> >>>>>>>>> An HttpServletRequest however can be wrapped multiple times and by >>>>>>>>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a >>>>>>>>> RequestDispatcher. >>>>>>>>> >>>>>>>>> The question now is; which version of the HttpServletRequest is >>>>>>>>> supposed >>>>>>>>> to be injected? >>>>>>>>> >>>>>>>>> * The first one in the chain? >>>>>>>>> * The last one in the chain? >>>>>>>>> * The current one at a given point in the chain? >>>>>>>>> >>>>>>>>> A little bit of experimenting seems to indicate it's now often >>>>>>>>> "one of >>>>>>>>> the first ones", e.g. the one that happened to be current when >>>>>>>>> e.g. a >>>>>>>>> ServletRequestListener that initialises a specific CDI >>>>>>>>> implementation is >>>>>>>>> called. >>>>>>>>> >>>>>>>>> I think this is a little confusing, as working with an injected >>>>>>>>> request >>>>>>>>> can now totally ignore the request wrapping that has been done and >>>>>>>>> break >>>>>>>>> an application badly. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Arjan Tijms >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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/20160908/263abae3/attachment-0001.html From mkouba at redhat.com Thu Sep 8 08:40:06 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 8 Sep 2016 14:40:06 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Dne 8.9.2016 v 14:28 arjan tijms napsal(a): > Hi, > > On Thu, Sep 8, 2016 at 2:14 PM, Martin Kouba > wrote: > > The best solution might be to let the servlet container provide the > beans for all the servlet artifacts (HttpServletRequest, HttpSession > and ServletContext). > > > +100 for that. > > Several issues were already created for that in the past, but to my > understanding it was misunderstood by some in the Servlet EG and > subsequently closed. See https://java.net/jira/browse/SERVLET_SPEC-116 > > Specifically this comment was a little problematic: > > GW> More over, > GW> I'm concerned that by making CDI to servlet mapping a responsibility > GW> of the servlet container, then we are going to have to do a > GW> container to CDI adaptation for every CDI implementation out there. > > I think this is missing the key insight that CDI extensions are portable > and that it's "just" providing a 1 class extension that adds 3 orso > build-in beans. Stuart has a good point about backward compatibility. Servlet impl would have to detect CDI version and skip registration if not 2.0+. I think SERVLET_SPEC-116 should be reopened and the discussion restarted. > > Kind regards, > Arjan Tijms > > > > > > > But it's more complicated then it sounds. For example, > HttpServletRequest attibutes might be used as backing storage of the > request context. So that it cannot simply change... > > Anyway, I think this problem deserves some attention from both the > CDI and the Servlet EG. > > Martin > > Dne 8.9.2016 v 13:31 arjan tijms napsal(a): > > Hi, > > On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau > > >> > wrote: > > Hit that issue as well several times. > > It is more vicious than it looks like IMO cause CDI will > *never* get > *the* right request for everybody, it is as simple as that. > Any part > of the app can rely on the wrapper level N (of course N being > different for each mentionned parts of the app). > > > What I was thinking, but maybe I'm wrong, is that the > application never > "just" wraps the request and uses it for itself. It always > passes it to > the container, which then passes it on to the next Filter, > Servlet, or > whatever. So at that point the container code has the opportunity to > store the request as being the "current" one. > > E.g. if you do: > > RequestDispatcher dispatcher = > servletContext().getRequestDispatcher(...); > dispatcher.forward(wrap(request), response); > > Then the RequestDispatcher, which is a container class, receives the > wrapped request and can make it available. > > The other way around, eventually every AuthModule, Filter or > Servlet has > to be called by the container at some point. E.g. the "protected > void > service(HttpServletRequest req, HttpServletResponse resp)" is > called by > the container. > > So just before the container invokes the HttpServlet#service > method, the > container can store the request, and CDI (via an SPI) can pick it up > from there. > > That way in every context you can always have the *current* > request (the > request that's passed in to the last Servlet or Filter call on > the stack). > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > > > > Best CDI can do is to provide the request it has (already > the case > and cost pretty much nothing) and enable the user to > produces very > easily its own request from its filter (or equivalent) for > its usage > IMO - which is IMO already doable but maybe there is another > shortcut we can introduce I didnt think about. If you look > one step > further any web framework built on top of CDI does it and > therefore > runs in a well known context. > > > Romain Manni-Bucau > @rmannibucau > | Blog > > | Old Wordpress Blog > > | Github > > | LinkedIn > > | Tomitriber > | JavaEE Factory > > > > 2016-09-08 13:03 GMT+02:00 arjan tijms > > >>: > > Hi, > > On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba > > >> > wrote: > > that's a good question. In Weld, the request object is > captured during request context activation, i.e. during > ServletRequestListener.requestInitialized() > notification and > before any filter or servlet is invoked. So wrappers are > ignored and the original/first request is used. > > > Indeed, although do note that some servers (Liberty and > WebLogic > I think) send the > ServletRequestListener.requestInitialized() > notification rather late, and do that after the application > already has seen the request and has had a chance to > wrap it. > This by itself is a separate problem. So on these > servers, Weld > would receive an early request but not necessarily the > earliest. > > > But TBH I don't think we can fix this easily as I'm not > aware of any portable way to listen for "wrapping > actions". > > > This would have to happen with Server specific code I guess, > just as Weld now requires an SPI to obtain the current > principal > for injection. > > You could say that the Servlet container could store the > request > "somewhere" on a stack structure, just before it invokes the > ServerAuthModule, Filter, Servlet and anything else I > may have > forgotten, and then when control flows back to each Servlet, > Filter, etc unwind that stack. > > At the very least the spec for now should perhaps > clarify this? > > Kind regards, > Arjan Tijms > > > > > > Martin > > Dne 8.9.2016 v 11:02 arjan tijms napsal(a): > > Hi, > > The CDI spec defines a built-in bean for the type > HttpServletRequest. In > 3.8 it says: > > "A servlet container must provide the following > built-in > beans, all of > which have qualifier @Default: > > a bean with bean type > javax.servlet.http.HttpServletRequest, allowing > injection of a reference to the HttpServletRequest" > > An HttpServletRequest however can be wrapped > multiple > times and by > multiple artefacts. I.e. by a ServerAuthModule, > Filter and a > RequestDispatcher. > > The question now is; which version of the > HttpServletRequest is supposed > to be injected? > > * The first one in the chain? > * The last one in the chain? > * The current one at a given point in the chain? > > A little bit of experimenting seems to indicate > it's now > often "one of > the first ones", e.g. the one that happened to be > current when e.g. a > ServletRequestListener that initialises a > specific CDI > implementation is > called. > > I think this is a little confusing, as working > with an > injected request > can now totally ignore the request wrapping that has > been done and break > an application badly. > > Thoughts? > > Kind regards, > Arjan Tijms > > > > _______________________________________________ > 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. > > > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From mkouba at redhat.com Thu Sep 8 08:44:31 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 8 Sep 2016 14:44:31 +0200 Subject: [cdi-dev] What to do to move CDI-30/PR 296 Forward In-Reply-To: References: <945764114.506964.1473278883963@mail.yahoo.com> Message-ID: <8e411717-1589-e4d2-4b25-74720e5fed68@redhat.com> Let's meet right after J1 then... Dne 8.9.2016 v 12:23 John Ament napsal(a): > TBH, its not going to happen for me before J1. > > > > ------------------------------------------------------------------------ > *From:* Antoine Sabot-Durand > *Sent:* Thursday, September 8, 2016 3:51 AM > *To:* Martin Kouba; John Ament; cdi-dev; Mark Struberg > *Subject:* Re: [cdi-dev] What to do to move CDI-30/PR 296 Forward > > John, Martin, > > > I think we really need to have a video hangout with you 2 and Mark to > restart discussion on the topic. What are your availability for such a > meeting? > > Antoine > > On Thu, Sep 8, 2016 at 9:06 AM Martin Kouba > wrote: > > Dne 7.9.2016 v 23:11 John Ament napsal(a): > > That's kind of an odd response. > > > > > > How does CDI-30 only work for request context? What makes you believe > > that? > > @RequestScoped - makes sense > @ApplicationScoped - is usually always active, no activation needed > @SessionScoped - activate/deactivate is not enough, you have to > associate the context with some storage > @ConversationScoped - even more complicated, you need a storage and > conversation ids > > > > > > > John > > > > > > > > > ------------------------------------------------------------------------ > > *From:* Mark Struberg > > > *Sent:* Wednesday, September 7, 2016 4:08 PM > > *To:* John Ament; Cdi-dev > > *Subject:* Re: [cdi-dev] What to do to move CDI-30/PR 296 Forward > > > > We have been burning our brains over this very topic, but it > doesn't yet > > feel sound. So I guess we will give it another few days/weeks to > tinker > > with it. > > > > The main downside of this api is that it's actually only useful > for the > > request context and only in SE. But we still add an API which looks to > > the user as it could use it for e.g. the ConversationContext, or > > existing servlet requests etc. It's complicated... > > > > I think we will first incorporate the parts which we found really nice > > solutions for. > > > > * Interceptor/Decorator for producer methods and custom Bean > > implementations > > * bean-discovery without automatically picking up all classes as > @Dependent > > * A few other minor tickets > > > > > > Should not take that long. After that we will have to tackle > CDI-30 for > > sure. > > > > > > LieGrue, > > strub > > > > > > > > On Wednesday, 7 September 2016, 19:04, John Ament > > > wrote: > >>All, > >> > >> > >>It seems like we're still stuck on CDI-30. Its been open, last > activity on Aug 2. I would love to see it closed and only reference > the use case agreed to - another library wants to integrate CDI into > its stack. To do so, it wants to be able to start and stop the > built in contexts. > >> > >> > >>John > >> > > > ------------------------------------------------------------------------ > > NOTICE: This e-mail message and any attachments may contain > > confidential, proprietary, and/or privileged information which > should be > > treated accordingly. If you are not the intended recipient, please > > notify the sender immediately by return e-mail, delete this > message, and > > destroy all physical and electronic copies. Thank you. > > > > > > _______________________________________________ > > 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. > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Thu Sep 8 09:03:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 8 Sep 2016 09:03:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-625: ----------------------------- Description: The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). Does it mean that: * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. I believe this should be more clear. was: The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). Does it mean that: * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. I believe this should be more clear. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Thu Sep 8 10:17:56 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 8 Sep 2016 16:17:56 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: Hi, On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba wrote: > I think this is missing the key insight that CDI extensions are portable >> and that it's "just" providing a 1 class extension that adds 3 orso >> build-in beans. >> > > Stuart has a good point about backward compatibility. Servlet impl would > have to detect CDI version and skip registration if not 2.0+. I think > SERVLET_SPEC-116 should be reopened and the discussion restarted. > Indeed, that is a good point, but that's basically part of the challenge of moving those build-in beans. If I'm not mistaken Antoine once mentioned in one of the other related issues something along the line that CDI 2.0 could provide something for that. So the "is 2.0+" check could be made easier or more straightforward. Kind regards, Arjan Tijms > > >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> But it's more complicated then it sounds. For example, >> HttpServletRequest attibutes might be used as backing storage of the >> request context. So that it cannot simply change... >> >> Anyway, I think this problem deserves some attention from both the >> CDI and the Servlet EG. >> >> Martin >> >> Dne 8.9.2016 v 13:31 arjan tijms napsal(a): >> >> Hi, >> >> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau >> >> >> >> >> wrote: >> >> Hit that issue as well several times. >> >> It is more vicious than it looks like IMO cause CDI will >> *never* get >> *the* right request for everybody, it is as simple as that. >> Any part >> of the app can rely on the wrapper level N (of course N being >> different for each mentionned parts of the app). >> >> >> What I was thinking, but maybe I'm wrong, is that the >> application never >> "just" wraps the request and uses it for itself. It always >> passes it to >> the container, which then passes it on to the next Filter, >> Servlet, or >> whatever. So at that point the container code has the opportunity >> to >> store the request as being the "current" one. >> >> E.g. if you do: >> >> RequestDispatcher dispatcher = >> servletContext().getRequestDispatcher(...); >> dispatcher.forward(wrap(request), response); >> >> Then the RequestDispatcher, which is a container class, receives >> the >> wrapped request and can make it available. >> >> The other way around, eventually every AuthModule, Filter or >> Servlet has >> to be called by the container at some point. E.g. the "protected >> void >> service(HttpServletRequest req, HttpServletResponse resp)" is >> called by >> the container. >> >> So just before the container invokes the HttpServlet#service >> method, the >> container can store the request, and CDI (via an SPI) can pick it >> up >> from there. >> >> That way in every context you can always have the *current* >> request (the >> request that's passed in to the last Servlet or Filter call on >> the stack). >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best CDI can do is to provide the request it has (already >> the case >> and cost pretty much nothing) and enable the user to >> produces very >> easily its own request from its filter (or equivalent) for >> its usage >> IMO - which is IMO already doable but maybe there is another >> shortcut we can introduce I didnt think about. If you look >> one step >> further any web framework built on top of CDI does it and >> therefore >> runs in a well known context. >> >> >> Romain Manni-Bucau >> @rmannibucau > > | Blog >> > > | Old Wordpress Blog >> > > | Github >> > > | LinkedIn >> > > | Tomitriber >> | JavaEE Factory >> > > >> >> 2016-09-08 13:03 GMT+02:00 arjan tijms >> >> >> >>: >> >> Hi, >> >> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >> >> >> >> >> wrote: >> >> that's a good question. In Weld, the request object is >> captured during request context activation, i.e. >> during >> ServletRequestListener.requestInitialized() >> notification and >> before any filter or servlet is invoked. So wrappers >> are >> ignored and the original/first request is used. >> >> >> Indeed, although do note that some servers (Liberty and >> WebLogic >> I think) send the >> ServletRequestListener.requestInitialized() >> notification rather late, and do that after the >> application >> already has seen the request and has had a chance to >> wrap it. >> This by itself is a separate problem. So on these >> servers, Weld >> would receive an early request but not necessarily the >> earliest. >> >> >> But TBH I don't think we can fix this easily as I'm >> not >> aware of any portable way to listen for "wrapping >> actions". >> >> >> This would have to happen with Server specific code I >> guess, >> just as Weld now requires an SPI to obtain the current >> principal >> for injection. >> >> You could say that the Servlet container could store the >> request >> "somewhere" on a stack structure, just before it invokes >> the >> ServerAuthModule, Filter, Servlet and anything else I >> may have >> forgotten, and then when control flows back to each >> Servlet, >> Filter, etc unwind that stack. >> >> At the very least the spec for now should perhaps >> clarify this? >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> Martin >> >> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >> >> Hi, >> >> The CDI spec defines a built-in bean for the type >> HttpServletRequest. In >> 3.8 it says: >> >> "A servlet container must provide the following >> built-in >> beans, all of >> which have qualifier @Default: >> >> a bean with bean type >> javax.servlet.http.HttpServletRequest, allowing >> injection of a reference to the >> HttpServletRequest" >> >> An HttpServletRequest however can be wrapped >> multiple >> times and by >> multiple artefacts. I.e. by a ServerAuthModule, >> Filter and a >> RequestDispatcher. >> >> The question now is; which version of the >> HttpServletRequest is supposed >> to be injected? >> >> * The first one in the chain? >> * The last one in the chain? >> * The current one at a given point in the chain? >> >> A little bit of experimenting seems to indicate >> it's now >> often "one of >> the first ones", e.g. the one that happened to be >> current when e.g. a >> ServletRequestListener that initialises a >> specific CDI >> implementation is >> called. >> >> I think this is a little confusing, as working >> with an >> injected request >> can now totally ignore the request wrapping that >> has >> been done and break >> an application badly. >> >> Thoughts? >> >> Kind regards, >> Arjan Tijms >> >> >> >> _______________________________________________ >> 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. >> >> >> >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160908/ac4caff4/attachment-0001.html From issues at jboss.org Thu Sep 8 11:13:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 8 Sep 2016 11:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-624 started by Antoine Sabot-Durand. ------------------------------------------------ > Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle > -------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-624 > URL: https://issues.jboss.org/browse/CDI-624 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > I believe we should not break the application initialization lifecycle. > So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean)}}. > The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 03:04:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 03:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290951#comment-13290951 ] Martin Kouba commented on CDI-627: ---------------------------------- bq. No Martin, I think in that case we miss if people ass java.lang.Object If so, then the wording should be something like: _If there is no class *OR* (the class is not annotated with @Alternative *AND* the class is not a bean class of a Bean with isAlternative() == true), the container automatically detects the problem..._ Note that the wording used in interceptors and decorators is also vague: bq. If there is no class with the specified name, or if the class with the specified name is not an interceptor class, the container automatically detects the problem... bq. If there is no class with the specified name, or if the class with the specified name is not a decorator bean class, the container automatically detects the problem... > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 03:16:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 9 Sep 2016 03:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290957#comment-13290957 ] Antoine Sabot-Durand commented on CDI-625: ------------------------------------------ EG decided during the F2F that {{@Destroyed}} events should be called *before* the destruction > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 03:40:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 03:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290970#comment-13290970 ] Mark Struberg commented on CDI-627: ----------------------------------- Pretty much spot on I think. We just have to properly word the bracket level ;) Probably with bullets If there is * no class exists with the given name, OR * the class is not annotated with @Alternative AND the class is not a bean class of a Bean with isAlternative() == true the container automatically detects the problem... > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 03:43:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 03:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290973#comment-13290973 ] Mark Struberg commented on CDI-627: ----------------------------------- Or simply word it the other way around (as proposed in my initial comment): For any listed in the section at least one of the following conditions must be met: * A class T exists which is annotated with @Alternative or contains a producer field or producer method which is annotated with @Alternative * There exists a Bean for the bean class with isAlternative() == true Otherwise the container automatically detects the problem... > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 04:06:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 04:06:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290986#comment-13290986 ] Martin Kouba commented on CDI-625: ---------------------------------- Note that this change will not be backward compatible. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 04:12:01 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 9 Sep 2016 04:12:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290990#comment-13290990 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- This will break apps relying on @PreDestroy to have been called already > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 07:15:03 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 07:15:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291105#comment-13291105 ] Martin Kouba commented on CDI-625: ---------------------------------- Alternatively, we could introduce a new qualifier/event. But it might be really hard to find a good name so that user don't get confused. {{@BeforeDestroyed}} does not seem to be the best choice. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:32:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 08:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291147#comment-13291147 ] Mark Struberg commented on CDI-625: ----------------------------------- Not quite sure about non-backward-compat. Afaik we currently didn't define when this event _exactly_ gets fired (before or after cleaning the Context). Nailing it to one of the 2 options will not make things worse. The users did rely on non portable behaviour anyway in that case. The reason is exactly that they would now be able to clean up their business stuff even if they need multiple beans for it. This was not possible if you rely on @PreDestroy in an applicationscoped bean as it is highly depending on the order in which the beans get destroyed. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:40:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 08:40:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291156#comment-13291156 ] Martin Kouba commented on CDI-625: ---------------------------------- Well, the wording is _"when the context is destroyed"_. I'm not a native speaker but it seems both OWB and Weld interpreted this (mostly) as "fire after destruction". > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:40:01 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 9 Sep 2016 08:40:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291157#comment-13291157 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- [~struberg] did we compare what is out there (= most common moment of the event?)? Can be the most relevant "standard". On the issue I think we need whatever is the outcome a Before/After these events (@Initiatlized as well) which is built in in CDI (= not another event). A bit like EventContext of arquillian maybe. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:47:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 08:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291165#comment-13291165 ] Martin Kouba commented on CDI-625: ---------------------------------- bq. A bit like EventContext of arquillian maybe. [~rmannibucau] I don't understand, pls elaborate... > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:54:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 08:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291172#comment-13291172 ] Mark Struberg commented on CDI-625: ----------------------------------- Firing such an explicit pre-destroy event for the application context is probably ok. But please lets not introduce this in a generic way ;) What speaks for not being a problem to move it generally to 'When the Application Context is about to be destroyed": Where can yo observe any @Destroyed(AppllicationContext.class) event if it would only get fired after the ApplicationContext gets shut down? For sure not in an @ApplicationContext scoped bean. Nor in any other CDI bean ;) > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:55:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 9 Sep 2016 08:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291173#comment-13291173 ] Romain Manni-Bucau edited comment on CDI-625 at 9/9/16 8:54 AM: ---------------------------------------------------------------- idea would be to have a default phase and allow to have a kind of interceptor for the event which would lead to the final proceed being the actual action. You can see it as the context.destroy() being intercepted by observers. Idea was: {code:java} public void around(@Observes @Destroyed(X.class) EventContext ctx) { // before context.destroy(); ctx.proceed(); // actual destroy // after context.destroy(), often in finally } {code} Concretely it would give a way to have interceptor feature on events which would enable to have interceptor-like on not managed beans. Built-in events could benefit from it. was (Author: rmannibucau): idea would be to have a default phase and allow to have a kind of interceptor for the event which would lead to the final proceed being the actual action. You can see it as the context.destroy() being intercepted by observers. Idea was: {code:java} public void around(@Observes @Destroyed(X.class) EventContext ctx) { // before context.destroy(); ctx.proceed(); // actual destroy // after context, often in finally } {code} Concretely it would give a way to have interceptor feature on events which would enable to have interceptor-like on not managed beans. Built-in events could benefit from it. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:55:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 9 Sep 2016 08:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291173#comment-13291173 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- idea would be to have a default phase and allow to have a kind of interceptor for the event which would lead to the final proceed being the actual action. You can see it as the context.destroy() being intercepted by observers. Idea was: {code:java} public void around(@Observes @Destroyed(X.class) EventContext ctx) { // before context.destroy(); ctx.proceed(); // actual destroy // after context, often in finally } {code} Concretely it would give a way to have interceptor feature on events which would enable to have interceptor-like on not managed beans. Built-in events could benefit from it. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 09:46:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 9 Sep 2016 09:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291223#comment-13291223 ] Tomas Remes commented on CDI-625: --------------------------------- This is interesting idea but I am not sure this "interceptor" concept fits well to this situation. What would happen in the case you have multiple observers of this kind? I guess you cannot call {{ctx.proceed())) multiple times. I am also not sure whether this is doable with this new payload type. It would mean to fire the event twice to stay at least little bit compatible. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 09:46:00 2016 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Fri, 9 Sep 2016 09:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291223#comment-13291223 ] Tomas Remes edited comment on CDI-625 at 9/9/16 9:45 AM: --------------------------------------------------------- This is interesting idea but I am not sure this "interceptor" concept fits well to this situation. What would happen in the case you have multiple observers of this kind? I guess you cannot call {{ctx.proceed()}} multiple times. I am also not sure whether this is doable with this new payload type. It would mean to fire the event twice to stay at least little bit compatible. was (Author: tremes): This is interesting idea but I am not sure this "interceptor" concept fits well to this situation. What would happen in the case you have multiple observers of this kind? I guess you cannot call {{ctx.proceed())) multiple times. I am also not sure whether this is doable with this new payload type. It would mean to fire the event twice to stay at least little bit compatible. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 09:48:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 09:48:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291226#comment-13291226 ] Martin Kouba commented on CDI-625: ---------------------------------- How about extending {{@Destroyed}}? {code:java} public @interface Destroyed { Class value(); boolean beforePhase() default false; } class Test { void observeAfter(@Observes @Destroyed(ApplicationScoped.class) Object object) { } void observeBefore(@Observes @Destroyed(value = ApplicationScoped.class, beforePhase = true) Object object) { } } {code} > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 09:57:01 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 09:57:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291231#comment-13291231 ] Mark Struberg commented on CDI-625: ----------------------------------- but then we need to fire them both. That is ok for ApplicationScoped but _not_ for e.g. RequestScoped. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:02:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 10:02:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291236#comment-13291236 ] Martin Kouba commented on CDI-625: ---------------------------------- [~struberg] Why is it not ok for {{@RequestScoped}}? Firing of these events can be easily optimized (e.g. noop if no observer exists). > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:05:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 10:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291240#comment-13291240 ] Mark Struberg commented on CDI-625: ----------------------------------- I checked OWB and we always fire it after destroying the beans right now. What does Weld do? > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:12:01 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 9 Sep 2016 10:12:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291251#comment-13291251 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- [~martinkouba] beforePhase would need another flag in the SPI API and therefore could break existing applications. [~tremes] ctx.proceed() would go to the next observer until the final invocation like interceptor chain. Since observers can be sorted with @Priority there is no big deal there. About compatibility since EventContext would be new we can say this is part of CDI bus and this is not a type you can fire directly without breaking anything. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:13:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 10:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291254#comment-13291254 ] Martin Kouba commented on CDI-625: ---------------------------------- As I already said above... _both OWB and Weld interpreted this (mostly) as "fire after destruction"_ (see also WELD-2229). > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:14:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 10:14:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291257#comment-13291257 ] Martin Kouba commented on CDI-625: ---------------------------------- [~rmannibucau] What "SPI API"? Adding a member with a default value to an annotation should be backward compatible. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:19:01 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 9 Sep 2016 10:19:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291262#comment-13291262 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- not if you add it programmatically (new DestroyedLiteral(....)) > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:22:01 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 10:22:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291263#comment-13291263 ] Mark Struberg commented on CDI-625: ----------------------------------- Hmm that really sounds like we should fire another event _before_ destroying. I don't like the interceptor way. Adds too much overhead I fear. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:38:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 9 Sep 2016 10:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291270#comment-13291270 ] Martin Kouba commented on CDI-625: ---------------------------------- [~rmannibucau] I see, you're right that existing literals would be broken. On the other hand, CDI API now provides its own literals which could be used instead. Also these literals are used mostly by CDI container itself. Rarely by extensions firing events for custom contexts and custom observer methods... -1 for "interceptor" approach. Looks unnecessarily complex. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:43:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 9 Sep 2016 10:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291275#comment-13291275 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- CDI provided literals are not yet mainstream and custom impl are still regularly seens so the breaking bck compat is a real concern IMO if interceptor approach is not liked we have to just define what we do I think. Not firing an event before makes sense since a bean with a @PreDestroy can always replace it (@Obserse init to init the bean then predestroy will be the before end event) > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 10:46:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 9 Sep 2016 10:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291277#comment-13291277 ] Mark Struberg commented on CDI-625: ----------------------------------- For all but @ApplicationScoped it's not really a problem. And for that we could introduce another new event probably? > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Sun Sep 11 15:02:49 2016 From: john.ament at spartasystems.com (John Ament) Date: Sun, 11 Sep 2016 19:02:49 +0000 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Message-ID: All, I was just thinking about alternatives and producer methods. Suppose I have the following bean: @ApplicationScoped public class Boop { @Produces @ApplicationScoped public Simpler makeSimpler() { return new Simpler("Boop"); } } If I want to override the producer method, I need to declare fully: @Alternative @Priority(100) @ApplicationScoped public class BoopAlternative extends Boop{ @Override @Produces public Simpler makeSimpler() { return new Simpler("Boop2"); } } For some reason, scopes are inherited, but the produces annotation is not. At least in the case of a producer method, it seems like it would be useful for @Produces to be inherited as well. John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160911/a3b4a45f/attachment.html From issues at jboss.org Sun Sep 11 17:28:00 2016 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Sun, 11 Sep 2016 17:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291532#comment-13291532 ] Emily Jiang commented on CDI-625: --------------------------------- +1 on creating a new event. The previous event did what it said though:). I think it correctly interpreted the meaning of Destroyed thought it is not useful. Perhaps the new event can be called @PreDestroying(X.class) > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From EMIJIANG at uk.ibm.com Sun Sep 11 17:59:50 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Sun, 11 Sep 2016 22:59:50 +0100 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: References: Message-ID: I think this is very problematic as you will get AmbiguousResolutionException all the time once we introduce this inheritance. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: cdi-dev Date: 11/09/2016 20:04 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org All, I was just thinking about alternatives and producer methods. Suppose I have the following bean: @ApplicationScoped public class Boop { @Produces @ApplicationScoped public Simpler makeSimpler() { return new Simpler("Boop"); } } If I want to override the producer method, I need to declare fully: @Alternative @Priority(100) @ApplicationScoped public class BoopAlternative extends Boop{ @Override @Produces public Simpler makeSimpler() { return new Simpler("Boop2"); } } For some reason, scopes are inherited, but the produces annotation is not. At least in the case of a producer method, it seems like it would be useful for @Produces to be inherited as well. John NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160911/8ad4dec8/attachment.html From issues at jboss.org Sun Sep 11 18:00:01 2016 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Sun, 11 Sep 2016 18:00:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291534#comment-13291534 ] Emily Jiang commented on CDI-627: --------------------------------- I prefer to clearly list the conditions for the DefintionException. It also matches other DefinitionException style. However, the following sentence is not well spelt out. * the class is not annotated with @Alternative AND the class is not a bean class of a Bean with isAlternative() == true I would suggest to stay similar to CDI 1.0 but change to the following or something similar If there is no class with the specified name, or if the class with the specified name is not an alternative bean class and no corresponding custom alternative bean class is defined, the container automatically detects the problem and treats it as a deployment problem. By the way, although we are fixing back cdi 1.2 to cdi 1.0, we are potentially introducing a backward incompatibility with cdi 1.2 spec. Any concerns? > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From john.ament at spartasystems.com Sun Sep 11 18:56:42 2016 From: john.ament at spartasystems.com (John Ament) Date: Sun, 11 Sep 2016 22:56:42 +0000 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: References: , Message-ID: Hi Emily, I disagree, at least it doesn't add any new ambiguous injections. The use-case is specifically to Specialized/Alternative beans. Right now inheritance of managed beans is itself problematic, as injecting the base class can cause these ambiguous resolutions. The example I sent out actually works correctly (in weld at least), really my propose is to remove the need to have Produces a second time and update the spec to clarify what happens here (FWIW, I don't believe the case is currently described in the spec), hopefully to say that qualifiers and scopes from the base method remain in effect, unless explicitly overridden. John ________________________________ From: Emily Jiang Sent: Sunday, September 11, 2016 5:59 PM To: John Ament Cc: cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? I think this is very problematic as you will get AmbiguousResolutionException all the time once we introduce this inheritance. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: cdi-dev Date: 11/09/2016 20:04 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org ________________________________ All, I was just thinking about alternatives and producer methods. Suppose I have the following bean: @ApplicationScoped public class Boop { @Produces @ApplicationScoped public Simpler makeSimpler() { return new Simpler("Boop"); } } If I want to override the producer method, I need to declare fully: @Alternative @Priority(100) @ApplicationScoped public class BoopAlternative extends Boop{ @Override @Produces public Simpler makeSimpler() { return new Simpler("Boop2"); } } For some reason, scopes are inherited, but the produces annotation is not. At least in the case of a producer method, it seems like it would be useful for @Produces to be inherited as well. John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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 Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160911/0e98097b/attachment-0001.html From struberg at yahoo.de Mon Sep 12 02:00:55 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 12 Sep 2016 06:00:55 +0000 (UTC) Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: References: Message-ID: <1416404859.2581553.1473660055325@mail.yahoo.com> > Right now inheritance of managed beans is itself problematic, as > injecting the base class can cause these ambiguous resolutions. Yes, that's why we originally introduced @Typed. Your sample wont work as an Alternative as it extends a concrete class and doesn't implement any interface. Did you mean @Specializes? Note that with @Alternative you won't make the original producer go away.You would also need to add @Alternative to the producer method imo. The rules for making an alternative producer method are really a bit confusing ;) I think the most portable way is to annotate both the class and the producer method with @Alternative. LieGrue, strub On Monday, 12 September 2016, 0:57, John Ament wrote: > >Hi Emily, > > >I disagree, at least it doesn't add any new ambiguous injections. The use-case is specifically to Specialized/Alternative beans. Right now inheritance of managed beans is itself problematic, as injecting the base class can cause these ambiguous resolutions. > > >The example I sent out actually works correctly (in weld at least), really my propose is to remove the need to have Produces a second time and update the spec to clarify what happens here (FWIW, I don't believe the case is currently described in the spec), hopefully to say that qualifiers and scopes from the base method remain in effect, unless explicitly overridden. > > >John > > > >________________________________ > >From: Emily Jiang >Sent: Sunday, September 11, 2016 5:59 PM >To: John Ament >Cc: cdi-dev >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > >I think this is very problematic as you will get AmbiguousResolutionException all the time once we introduce this inheritance. > >Many thanks, >Emily >=========================== >Emily Jiang >WebSphere Application Server, CDI Development Lead > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN >Phone: +44 (0)1962 816278 Internal: 246278 > >Email: emijiang at uk.ibm.com >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > >From: John Ament >To: cdi-dev >Date: 11/09/2016 20:04 >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? >Sent by: cdi-dev-bounces at lists.jboss.org >>________________________________ > > > >All, > >I was just thinking about alternatives and producer methods. Suppose I have the following bean: > >@ApplicationScoped >public class Boop { > > @Produces > @ApplicationScoped > public Simpler makeSimpler() { > return new Simpler("Boop"); > } >} > >If I want to override the producer method, I need to declare fully: > >@Alternative >@Priority(100) >@ApplicationScoped >public class BoopAlternative extends Boop{ > @Override > @Produces > public Simpler makeSimpler() { > return new Simpler("Boop2"); > } >} > >For some reason, scopes are inherited, but the produces annotation is not. At least in the case of a producer method, it seems like it would be useful for @Produces to be inherited as well. > >John > >________________________________ > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ >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 Info Page - JBoss Developer >lists.jboss.org >List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > >Unless stated otherwise above: >IBM United Kingdom Limited - Registered in England and Wales with number 741598. >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > >________________________________ > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. > >_______________________________________________ >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 Sep 12 03:04:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 12 Sep 2016 03:04:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291583#comment-13291583 ] Martin Kouba commented on CDI-625: ---------------------------------- [~rmannibucau] Yep, the CDI-provided literals are not used yet and I agree it's a backward compatibility risk. However, {{@PreDestroy}} CANNOT always replace this functionality - the ordering of destruction is not defined and so beans are not allowed to call other beans from within {{@PreDestroy}} callback (see also CDI-625). [~struberg] [~emilyj] So I believe we should introduce a new event, for all built-in scopes. {{@PreDestroying(X.class)}} is imho confusing. Maybe something like {{@BeforeDestroyed(X.class)}}. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 03:09:01 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 12 Sep 2016 03:09:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291585#comment-13291585 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- [~mkouba] being said today the behavior is uniform and the predestroy issue you describe actual it is always possible to use predestroy merging them in a bean (or more commonly having an orchestrator bean intended for the destruction) is beforeshutdown defined in this shutdown lifecycle? if not shouldnt it be the solution? I know it has been prevented but supporting it in any bean would work I think > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 03:15:02 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 12 Sep 2016 03:15:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291589#comment-13291589 ] Martin Kouba commented on CDI-625: ---------------------------------- bq. ...it is always possible to use predestroy merging them in a bean... Not really. If you have application scoped Bean1 and Bean2 you cannot simply create Bean3 and destoy them there... in other words, this "merging" is not always possible. bq. is beforeshutdown defined in this shutdown lifecycle? {{BeforeShutdown}} is a container lifecycle event and is fired after all contexts are destroyed. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 03:26:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 12 Sep 2016 03:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291593#comment-13291593 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- You can always remove @PreDestroy in an extension and call it in Bean3 but was more thinking this way: since the user hits this issue the workaround is to not use @PreDestroy when it is an issue or order is important (which is not that common compared to @PreDestroy cases). Right about BeforeShutdown, know early OWB versions needed to move it before the actual destruction in some cases (could check the details and current state if needed) cause BeforeShutdown extensions are often accessing app scoped beans which was not possible in the mentionned order, maybe no more an issue with this new @BeforeDestroyed. About the semantic if we introduce @BeforeDestroyed we should likely introduce @AfterDestroyed for the consistency and do the same for @Initialized which would let us with two events doing the same in term or API (but easily collapsable in the implementation so no perf issue, just an API issue). Is that possible to deprecate not prefixed events? Or maybe @AfterXX should be a @Stereotype which would auto document the new API? > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From manovotn at redhat.com Mon Sep 12 03:28:17 2016 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 12 Sep 2016 03:28:17 -0400 (EDT) Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: <1416404859.2581553.1473660055325@mail.yahoo.com> References: <1416404859.2581553.1473660055325@mail.yahoo.com> Message-ID: <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> Hi all, I did some testing (with Weld) and it seems the scope IS inherited when you use @Alternative. However it IS NOT inherited when you use @Specialized. Not yet sure if this is intended or anyhow spec-defined, just stating facts. Matej ----- Original Message ----- > From: "Mark Struberg" > To: "John Ament" , "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, September 12, 2016 8:00:55 AM > Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > > > Right now inheritance of managed beans is itself problematic, as > > > injecting the base class can cause these ambiguous resolutions. > > Yes, that's why we originally introduced @Typed. > > > > Your sample wont work as an Alternative as it extends a concrete class and > doesn't implement any interface. > Did you mean @Specializes? > Note that with @Alternative you won't make the original producer go away.You > would also need to add @Alternative to the producer method imo. The rules > for making an alternative producer method are really a bit confusing ;) I > think the most portable way is to annotate both the class and the producer > method with @Alternative. > > > LieGrue, > strub > > > On Monday, 12 September 2016, 0:57, John Ament > wrote: > > > >Hi Emily, > > > > > >I disagree, at least it doesn't add any new ambiguous injections. The > >use-case is specifically to Specialized/Alternative beans. Right now > >inheritance of managed beans is itself problematic, as injecting the base > >class can cause these ambiguous resolutions. > > > > > >The example I sent out actually works correctly (in weld at least), really > >my propose is to remove the need to have Produces a second time and update > >the spec to clarify what happens here (FWIW, I don't believe the case is > >currently described in the spec), hopefully to say that qualifiers and > >scopes from the base method remain in effect, unless explicitly overridden. > > > > > >John > > > > > > > >________________________________ > > > >From: Emily Jiang > >Sent: Sunday, September 11, 2016 5:59 PM > >To: John Ament > >Cc: cdi-dev > >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > >I think this is very problematic as you will get > >AmbiguousResolutionException all the time once we introduce this > >inheritance. > > > >Many thanks, > >Emily > >=========================== > >Emily Jiang > >WebSphere Application Server, CDI Development Lead > > > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > >Phone: +44 (0)1962 816278 Internal: 246278 > > > >Email: emijiang at uk.ibm.com > >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > >From: John Ament > >To: cdi-dev > >Date: 11/09/2016 20:04 > >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be > >inherited? > >Sent by: cdi-dev-bounces at lists.jboss.org > >>________________________________ > > > > > > > >All, > > > >I was just thinking about alternatives and producer methods. Suppose I have > >the following bean: > > > >@ApplicationScoped > >public class Boop { > > > > @Produces > > @ApplicationScoped > > public Simpler makeSimpler() { > > return new Simpler("Boop"); > > } > >} > > > >If I want to override the producer method, I need to declare fully: > > > >@Alternative > >@Priority(100) > >@ApplicationScoped > >public class BoopAlternative extends Boop{ > > @Override > > @Produces > > public Simpler makeSimpler() { > > return new Simpler("Boop2"); > > } > >} > > > >For some reason, scopes are inherited, but the produces annotation is not. > >At least in the case of a producer method, it seems like it would be > >useful for @Produces to be inherited as well. > > > >John > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > _______________________________________________ > >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 Info Page - JBoss Developer > >lists.jboss.org > >List to discuss the development of CDI (the specification) To see the > >collection of prior postings to the list, visit the cdi-dev Archives. > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with number > >741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > >_______________________________________________ > >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 issues at jboss.org Mon Sep 12 03:50:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 12 Sep 2016 03:50:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291603#comment-13291603 ] Martin Kouba commented on CDI-625: ---------------------------------- bq. BeforeShutdown extensions are often accessing app scoped beans... Not legal and should not work. bq. @AfterDestroyed for the consistency... Yep, we could introduce {{@AfterDestroyed}} and deprecate {{@Destroyed}}. The event could be fired with both of these qualifiers - the old observers (with {{@Destroyed}}) should still work as they have a subset of the event qualifiers. bq. and do the same for @Initialized I don't think it's needed. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 03:59:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 12 Sep 2016 03:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291608#comment-13291608 ] Mark Struberg commented on CDI-627: ----------------------------------- Imo no concern as we just fix a regression introduced in the 1.2 wording. One could argue that this limitation is actually not valid for 1.2 anyway as we must not introduce such backward incompat changes in a follow up spec version. > fix wording regression for beans.xml alternative check introduced in 1.2 > ------------------------------------------------------------------------ > > Key: CDI-627 > URL: https://issues.jboss.org/browse/CDI-627 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Fix For: 2.0 (proposed) > > > My scenario is the following: > I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite. > {code} > @Alternative > @ApplicationScoped > @Exclude(ifProjectStage=Production.class) > public class MockMailService implements MailService {...} > {code} > Of course I only need to activate it in beans.xml: > {code} > > > org.acme.MockMailService > > > {code} > This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive". > Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases! > What the intention was: all is fine IF one of > * There exists a class T with the given name > * That class T (or a contained producer field or producer method) is annotated with @Alternative > * There is a Bean with isAlternative() == true -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 04:05:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 12 Sep 2016 04:05:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291612#comment-13291612 ] Romain Manni-Bucau commented on CDI-625: ---------------------------------------- bq. Not legal and should not work. Well CDI doesn't solve it so we have to provide a real life solution to solve your @PreDestroy issue in an extension but should be solve by this jira so let's skip this one since it was a pre-solution case ;) bq. I don't think it's needed. Agree before doesnt make sense but weird to not be symmetric there from a user perspective. I would at least enhance the After behavior > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 05:43:01 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 12 Sep 2016 05:43:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291672#comment-13291672 ] Antoine Sabot-Durand commented on CDI-628: ------------------------------------------ -1 as well. It could looks like a nice feature but as others said it breaks CDI concept and will need to a nightmare. Using extensions or a producer to declare a new bean with a different scope from an existing dependent bean seems a better choice. > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 05:43:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 12 Sep 2016 05:43:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-628. ------------------------------------ Resolution: Rejected > Allow overriding of Scope at Injection Point > -------------------------------------------- > > Key: CDI-628 > URL: https://issues.jboss.org/browse/CDI-628 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 (proposed) > Reporter: Stephan Knitelius > Priority: Minor > > Allow overriding scopes at injection point. > {code} > @SessionScope > public class FeatureState {...} > public class Bean B { > @Inject > @ConversationScoped //Overriding original scope > public BeanA beanA; > ... > } > {code} > Sample use-case for for a feature flag: > {code} > @Alternative > public class FeatureStateProducer { > @Inject > @SessionScoped > private FeatureState devState; > @Inject > @ConversationScoped > private FeatureState viewState; > @Inject > private JNDIProvider jndiProvider; > private boolean viewOnly = true; > @PostConstruct > public void postConstruct() { > this.viewMode = ...; //read config. > } > @Produces > public FeatureState produce() { > return viewOnly ? viewState : devState; > } > } > {code} > Currently this can be solved by overriding scope with @Qualifiers: > {code} > @ViewMode > @ConversationScoped > public class ViewFeatureState extends FeatureState {...} > @DevMode > @SessionScoped > public class DevFeatureState extends FeatureState {...} > {code} > Risks: > * developers might start to define the scopes at IP and on bean (hard to maintain). > * confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving differently. > * etc... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Mon Sep 12 06:28:23 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 12 Sep 2016 12:28:23 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? Message-ID: Hi, Wouldn't it be convenient as the CDI API that now requires an Annotation instance in various APIs, would also accept the class type of that Annotation? E.g. in BeanManager there's this method: Set> getBeans(Type beanType, Annotation... qualifiers) This not rarely requires one to create an AnnotationLiteral, which is not specifically difficult but a tad verbose. For qualifiers that have no (binding) attributes, a simple Class would be much easier to use. Thoughts? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160912/4f276785/attachment.html From rmannibucau at gmail.com Mon Sep 12 06:34:14 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 12 Sep 2016 12:34:14 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: References: Message-ID: Think it is maybe saner to have AnnotationProvider.of(type, params) (like in deltaspike) since it doesnt leave the parameterized annotations (which are not rare) next the road. Romain Manni-Bucau @rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | Tomitriber | JavaEE Factory 2016-09-12 12:28 GMT+02:00 arjan tijms : > Hi, > > Wouldn't it be convenient as the CDI API that now requires an Annotation > instance in various APIs, would also accept the class type of that > Annotation? > > E.g. in BeanManager there's this method: > > Set> getBeans(Type beanType, Annotation... qualifiers) > > This not rarely requires one to create an AnnotationLiteral, which is not > specifically difficult but a tad verbose. For qualifiers that have no > (binding) attributes, a simple Class would be much easier to use. > > Thoughts? > > Kind regards, > Arjan Tijms > > _______________________________________________ > 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/20160912/091b6919/attachment-0001.html From mkouba at redhat.com Mon Sep 12 07:44:43 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 12 Sep 2016 13:44:43 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: References: Message-ID: <73ae8f28-f675-c932-b0eb-c1d8acde5829@redhat.com> Type safety is not guaranteed in the current version of AnnotationInstanceProvider (deltaspike). We should at least check the provided map of member values against the set of declared methods. Otherwise, I like the idea of standardizing a similar "annotation instance builder". Martin Dne 12.9.2016 v 12:34 Romain Manni-Bucau napsal(a): > Think it is maybe saner to have AnnotationProvider.of(type, params) > (like in deltaspike) since it doesnt leave the parameterized annotations > (which are not rare) next the road. > > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Wordpress Blog > | Github > | LinkedIn > | Tomitriber > | JavaEE Factory > > > 2016-09-12 12:28 GMT+02:00 arjan tijms >: > > Hi, > > Wouldn't it be convenient as the CDI API that now requires an > Annotation instance in various APIs, would also accept the class > type of that Annotation? > > E.g. in BeanManager there's this method: > > Set> getBeans(Type beanType, Annotation... qualifiers) > > This not rarely requires one to create an AnnotationLiteral, which > is not specifically difficult but a tad verbose. For qualifiers that > have no (binding) attributes, a simple Class would be much easier to > use. > > Thoughts? > > Kind regards, > Arjan Tijms > > _______________________________________________ > 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 arjan.tijms at gmail.com Mon Sep 12 08:14:52 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 12 Sep 2016 14:14:52 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: <73ae8f28-f675-c932-b0eb-c1d8acde5829@redhat.com> References: <73ae8f28-f675-c932-b0eb-c1d8acde5829@redhat.com> Message-ID: Hi, Annotation builder would be +1. It's a tiny bit less convenient, but more universal. So better for the spec. Convenience addition could theoretically still be: Set> getBeans(Type beanType, Class annotationType, Object... annotation attributes); But... I acknowledge that this would again be for a more specific situation (namely, a bean with exactly 1 qualifier and 0 or more binding attributes). While on the subject, it's currently not possible for an injected bean to get hold of the annotation instance that's used in CDI.current().select(), BeanManager.getBeans, etc, is it? Kind regards, Arjan Tijms On Mon, Sep 12, 2016 at 1:44 PM, Martin Kouba wrote: > Type safety is not guaranteed in the current version of > AnnotationInstanceProvider (deltaspike). We should at least check the > provided map of member values against the set of declared methods. > Otherwise, I like the idea of standardizing a similar "annotation instance > builder". > > Martin > > Dne 12.9.2016 v 12:34 Romain Manni-Bucau napsal(a): > >> Think it is maybe saner to have AnnotationProvider.of(type, params) >> (like in deltaspike) since it doesnt leave the parameterized annotations >> (which are not rare) next the road. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog >> | Old Wordpress Blog >> | Github >> | LinkedIn >> | Tomitriber >> | JavaEE Factory >> >> >> 2016-09-12 12:28 GMT+02:00 arjan tijms > >: >> >> Hi, >> >> Wouldn't it be convenient as the CDI API that now requires an >> Annotation instance in various APIs, would also accept the class >> type of that Annotation? >> >> E.g. in BeanManager there's this method: >> >> Set> getBeans(Type beanType, Annotation... qualifiers) >> >> This not rarely requires one to create an AnnotationLiteral, which >> is not specifically difficult but a tad verbose. For qualifiers that >> have no (binding) attributes, a simple Class would be much easier to >> use. >> >> Thoughts? >> >> Kind regards, >> Arjan Tijms >> >> _______________________________________________ >> 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/license >> s/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/20160912/45f348bd/attachment.html From john.ament at spartasystems.com Mon Sep 12 08:28:51 2016 From: john.ament at spartasystems.com (John Ament) Date: Mon, 12 Sep 2016 12:28:51 +0000 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> References: <1416404859.2581553.1473660055325@mail.yahoo.com>, <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> Message-ID: @Matej - Yes, that would be consistent with what I was seeing as well. @Mark - Are you thinking about decorators and not alternatives? See also [1] Really the goal here is to substitute the bean, but not just the provided bean the producer method that it exposes. It seems to work as I would expect it in weld (as mentioned), when I add @Produces to the method, it overrides the base class's producer method. No ambiguous resolutions, it just works properly. Realistically, this is all an experiment to see if I can provide spring boot like default configurations (beans, config values, etc) in a framework, and override them as an application developer. [1]: http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#alternatives ________________________________ From: Matej Novotny Sent: Monday, September 12, 2016 3:28 AM To: Mark Struberg Cc: John Ament; Emily Jiang; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Hi all, I did some testing (with Weld) and it seems the scope IS inherited when you use @Alternative. However it IS NOT inherited when you use @Specialized. Not yet sure if this is intended or anyhow spec-defined, just stating facts. Matej ----- Original Message ----- > From: "Mark Struberg" > To: "John Ament" , "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, September 12, 2016 8:00:55 AM > Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > > > Right now inheritance of managed beans is itself problematic, as > > > injecting the base class can cause these ambiguous resolutions. > > Yes, that's why we originally introduced @Typed. > > > > Your sample wont work as an Alternative as it extends a concrete class and > doesn't implement any interface. > Did you mean @Specializes? > Note that with @Alternative you won't make the original producer go away.You > would also need to add @Alternative to the producer method imo. The rules > for making an alternative producer method are really a bit confusing ;) I > think the most portable way is to annotate both the class and the producer > method with @Alternative. > > > LieGrue, > strub > > > On Monday, 12 September 2016, 0:57, John Ament > wrote: > > > >Hi Emily, > > > > > >I disagree, at least it doesn't add any new ambiguous injections. The > >use-case is specifically to Specialized/Alternative beans. Right now > >inheritance of managed beans is itself problematic, as injecting the base > >class can cause these ambiguous resolutions. > > > > > >The example I sent out actually works correctly (in weld at least), really > >my propose is to remove the need to have Produces a second time and update > >the spec to clarify what happens here (FWIW, I don't believe the case is > >currently described in the spec), hopefully to say that qualifiers and > >scopes from the base method remain in effect, unless explicitly overridden. > > > > > >John > > > > > > > >________________________________ > > > >From: Emily Jiang > >Sent: Sunday, September 11, 2016 5:59 PM > >To: John Ament > >Cc: cdi-dev > >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > >I think this is very problematic as you will get > >AmbiguousResolutionException all the time once we introduce this > >inheritance. > > > >Many thanks, > >Emily > >=========================== > >Emily Jiang > >WebSphere Application Server, CDI Development Lead > > > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > >Phone: +44 (0)1962 816278 Internal: 246278 > > > >Email: emijiang at uk.ibm.com > >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > >From: John Ament > >To: cdi-dev > >Date: 11/09/2016 20:04 > >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be > >inherited? > >Sent by: cdi-dev-bounces at lists.jboss.org > >>________________________________ > > > > > > > >All, > > > >I was just thinking about alternatives and producer methods. Suppose I have > >the following bean: > > > >@ApplicationScoped > >public class Boop { > > > > @Produces > > @ApplicationScoped > > public Simpler makeSimpler() { > > return new Simpler("Boop"); > > } > >} > > > >If I want to override the producer method, I need to declare fully: > > > >@Alternative > >@Priority(100) > >@ApplicationScoped > >public class BoopAlternative extends Boop{ > > @Override > > @Produces > > public Simpler makeSimpler() { > > return new Simpler("Boop2"); > > } > >} > > > >For some reason, scopes are inherited, but the produces annotation is not. > >At least in the case of a producer method, it seems like it would be > >useful for @Produces to be inherited as well. > > > >John > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > _______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/cdi-dev cdi-dev Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > > >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 Info Page - JBoss Developer > >lists.jboss.org > >List to discuss the development of CDI (the specification) To see the > >collection of prior postings to the list, visit the cdi-dev Archives. > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with number > >741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > >_______________________________________________ > >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. > ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160912/02feb599/attachment-0001.html From issues at jboss.org Mon Sep 12 10:08:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 12 Sep 2016 10:08:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-629) Consider standardizing AnnotationInstaceProvider from DeltaSpike In-Reply-To: References: Message-ID: Martin Kouba created CDI-629: -------------------------------- Summary: Consider standardizing AnnotationInstaceProvider from DeltaSpike Key: CDI-629 URL: https://issues.jboss.org/browse/CDI-629 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba Fix For: 2.0 (discussion) http://lists.jboss.org/pipermail/cdi-dev/2016-September/008829.html Impl. notes: * the type safety is not guaranteed in the current version of {{AnnotationInstanceProvider}} (deltaspike) * {{AnnotationInstanceProvider}} implements {{Serializable}} but a user is allowed to provide a map instance which is not serializable or contains values which are not serializable * the provided map of values should be copied (it can be mutable) * we should at least check the provided map of member values against the set of declared methods -- This message was sent by Atlassian JIRA (v6.4.11#64026) From mkouba at redhat.com Mon Sep 12 10:09:05 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 12 Sep 2016 16:09:05 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: References: <73ae8f28-f675-c932-b0eb-c1d8acde5829@redhat.com> Message-ID: I've created https://issues.jboss.org/browse/CDI-629 Dne 12.9.2016 v 14:14 arjan tijms napsal(a): > Hi, > > Annotation builder would be +1. It's a tiny bit less convenient, but > more universal. So better for the spec. > > Convenience addition could theoretically still be: > > Set> getBeans(Type beanType, Class annotationType, Object... > annotation attributes); > > But... I acknowledge that this would again be for a more specific > situation (namely, a bean with exactly 1 qualifier and 0 or more binding > attributes). > > While on the subject, it's currently not possible for an injected bean > to get hold of the annotation instance that's used in > CDI.current().select(), BeanManager.getBeans, etc, is it? No and I cannot imagine a way to do this. > > Kind regards, > Arjan Tijms > > > > > > > > > > On Mon, Sep 12, 2016 at 1:44 PM, Martin Kouba > wrote: > > Type safety is not guaranteed in the current version of > AnnotationInstanceProvider (deltaspike). We should at least check > the provided map of member values against the set of declared > methods. Otherwise, I like the idea of standardizing a similar > "annotation instance builder". > > Martin > > Dne 12.9.2016 v 12:34 Romain Manni-Bucau napsal(a): > > Think it is maybe saner to have AnnotationProvider.of(type, params) > (like in deltaspike) since it doesnt leave the parameterized > annotations > (which are not rare) next the road. > > > Romain Manni-Bucau > @rmannibucau > | Blog > > | Old Wordpress Blog > > | Github > > | LinkedIn > > | Tomitriber > | JavaEE Factory > > > > 2016-09-12 12:28 GMT+02:00 arjan tijms > >>: > > Hi, > > Wouldn't it be convenient as the CDI API that now requires an > Annotation instance in various APIs, would also accept the class > type of that Annotation? > > E.g. in BeanManager there's this method: > > Set> getBeans(Type beanType, Annotation... qualifiers) > > This not rarely requires one to create an AnnotationLiteral, > which > is not specifically difficult but a tad verbose. For > qualifiers that > have no (binding) attributes, a simple Class would be much > easier to > use. > > Thoughts? > > Kind regards, > Arjan Tijms > > _______________________________________________ > 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. > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From issues at jboss.org Mon Sep 12 10:23:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 12 Sep 2016 10:23:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: Martin Kouba created CDI-630: -------------------------------- Summary: Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode Key: CDI-630 URL: https://issues.jboss.org/browse/CDI-630 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 10:23:01 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 12 Sep 2016 10:23:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-630: ----------------------------- Fix Version/s: 2.0 (discussion) > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 13:18:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 12 Sep 2016 13:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292101#comment-13292101 ] Mark Struberg commented on CDI-630: ----------------------------------- -1 that would be incompatible with native annotations! https://docs.oracle.com/javase/7/docs/api/java/lang/annotation/Annotation.html#hashCode() > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 12 14:27:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 12 Sep 2016 14:27:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292123#comment-13292123 ] Mark Struberg commented on CDI-630: ----------------------------------- Kids sleeping, now is time for the long explanation: The hascode for empty annotations is defined as zero, Imagine a class {code} @Default @ApplicationScoped public class Bla {... {code} now put this annotation in a HashMap: {code} map.put(Bla.class.getAnnotation(Default.class)); {code} And we also have another dynamic annotation {code} map.put( new AnnotationLiteral {} ); {code} If we would change the hashCode of empty AnnotationLiterals then you would end up with 2 entries in the HashMap. > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Mon Sep 12 14:43:57 2016 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 12 Sep 2016 18:43:57 +0000 (UTC) Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: References: <73ae8f28-f675-c932-b0eb-c1d8acde5829@redhat.com> Message-ID: <421916788.3098442.1473705837444@mail.yahoo.com> Well, the DeltaSpike AnnotationInstanceProvider (or OWB 'DefaultAnnotation' as it used to be called) exist for a slightly different reason: With AnnotationLiteral you need to know the class you want an Annotation for already at compile time. The DeltaSpike AnnotationInstanceProvider does the same but fully dynamic. That way you can create an empty Annotation instance just by having e.g. the classname as String. I use it e.g. to create an interceptor binding Annotation from a configuration file: https://github.com/struberg/InterDyn/blob/master/interdyn/src/main/java/at/struct/devtools/cdi/interdyn/InterDynExtension.java#L172 LieGrue, strub On Monday, 12 September 2016, 14:16, arjan tijms wrote: > > >Hi, > > >Annotation builder would be +1. It's a tiny bit less convenient, but more universal. So better for the spec. > > >Convenience addition could theoretically still be: > >Set> getBeans(Type beanType, Class annotationType, Object... annotation attributes); > > > >But... I acknowledge that this would again be for a more specific situation (namely, a bean with exactly 1 qualifier and 0 or more binding attributes). > > >While on the subject, it's currently not possible for an injected bean to get hold of the annotation instance that's used in CDI.current().select(), BeanManager.getBeans, etc, is it? > > >Kind regards, >Arjan Tijms > > > > > > > > > > > > > > > > > > >On Mon, Sep 12, 2016 at 1:44 PM, Martin Kouba wrote: > >Type safety is not guaranteed in the current version of AnnotationInstanceProvider (deltaspike). We should at least check the provided map of member values against the set of declared methods. Otherwise, I like the idea of standardizing a similar "annotation instance builder". >> >>Martin >> >>Dne 12.9.2016 v 12:34 Romain Manni-Bucau napsal(a): >> >>Think it is maybe saner to have AnnotationProvider.of(type, params) >>>(like in deltaspike) since it doesnt leave the parameterized annotations >>>(which are not rare) next the road. >>> >>> >>>Romain Manni-Bucau >>> @rmannibucau | Blog >>> | Old Wordpress Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> | JavaEE Factory >>> >>> >>>2016-09-12 12:28 GMT+02:00 arjan tijms >> >: >>> >>> Hi, >>> >>> Wouldn't it be convenient as the CDI API that now requires an >>> Annotation instance in various APIs, would also accept the class >>> type of that Annotation? >>> >>> E.g. in BeanManager there's this method: >>> >>> Set> getBeans(Type beanType, Annotation... qualifiers) >>> >>> This not rarely requires one to create an AnnotationLiteral, which >>> is not specifically difficult but a tad verbose. For qualifiers that >>> have no (binding) attributes, a simple Class would be much easier to >>> use. >>> >>> Thoughts? >>> >>> Kind regards, >>> Arjan Tijms >>> >>> ______________________________ _________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailma n/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/license s/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/mailma n/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/license s/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 issues at jboss.org Tue Sep 13 02:18:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 13 Sep 2016 02:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292251#comment-13292251 ] Matej Novotny commented on CDI-630: ----------------------------------- So, if I get this right, then we are basically stuck here because our {{hashCode}} impl has to be alligned with that defined by {{java.lang.annotation.Annotation}}? And the reason behind that is that people are able to use both approaches ({{class.getAnnotation}} and {{AnnotationLiteral}}) and the results would then differ. > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 03:04:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 13 Sep 2016 03:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292264#comment-13292264 ] Martin Kouba commented on CDI-630: ---------------------------------- bq. If we would change the hashCode of empty AnnotationLiterals then you would end up with 2 entries in the HashMap. [~struberg] No, you will not end up with 2 entries because those annotation instances are equal. From what I know the hash code is only used to compute an index into array of buckets. So right now all annotation literal keys will end up in one bucket (-> hash collisions -> less effective lookup). But I agree we MAY NOT break the {{java.lang.annotation.Annotation.hashCode()}} contract - I wasn't aware of its existence :-( Still, I don't get the meaning of storing a zero integer if there are no members. Checking the members array length should be fine. Lowering the priority... > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 03:04:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 13 Sep 2016 03:04:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-630: ----------------------------- Priority: Optional (was: Major) > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Priority: Optional > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 03:06:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 13 Sep 2016 03:06:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-630: ----------------------------- Description: Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should -either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or- simply return zero and don't cache the value at all. UPDATE: We may not return a number based on the annotation type because it would break the {{java.lang.annotation.Annotation.hashCode()}} contract. was:Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all. > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Priority: Optional > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should -either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or- simply return zero and don't cache the value at all. > UPDATE: We may not return a number based on the annotation type because it would break the {{java.lang.annotation.Annotation.hashCode()}} contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 03:18:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 13 Sep 2016 03:18:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292264#comment-13292264 ] Martin Kouba edited comment on CDI-630 at 9/13/16 3:17 AM: ----------------------------------------------------------- bq. If we would change the hashCode of empty AnnotationLiterals then you would end up with 2 entries in the HashMap. [~struberg] No, you don't have to end up with 2 entries because those annotation instances are equal. From what I know the hash code is only used to compute an index into array of buckets. But it really depends on impl. So right now all annotation literal keys will end up in one bucket (-> hash collisions -> less effective lookup). Anyway, we would break the general equals/contract and also the {{java.lang.annotation.Annotation.hashCode()}} contract (I wasn't aware of its existence :-(. So it's definitely NOT POSSIBLE. Still, I don't get the meaning of storing a zero integer if there are no members. Checking the members array length should be fine. Lowering the priority... was (Author: mkouba): bq. If we would change the hashCode of empty AnnotationLiterals then you would end up with 2 entries in the HashMap. [~struberg] No, you will not end up with 2 entries because those annotation instances are equal. From what I know the hash code is only used to compute an index into array of buckets. So right now all annotation literal keys will end up in one bucket (-> hash collisions -> less effective lookup). But I agree we MAY NOT break the {{java.lang.annotation.Annotation.hashCode()}} contract - I wasn't aware of its existence :-( Still, I don't get the meaning of storing a zero integer if there are no members. Checking the members array length should be fine. Lowering the priority... > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Priority: Optional > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should -either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or- simply return zero and don't cache the value at all. > UPDATE: We may not return a number based on the annotation type because it would break the {{java.lang.annotation.Annotation.hashCode()}} contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 03:39:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 13 Sep 2016 03:39:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292283#comment-13292283 ] Mark Struberg commented on CDI-630: ----------------------------------- You will end up with 2 instances, think about it again ;) Of course equals() would return true, but hashCode is different. You are right with hash collision, but the other way we end up with not finding the right instances :( > Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode > ------------------------------------------------------------- > > Key: CDI-630 > URL: https://issues.jboss.org/browse/CDI-630 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Priority: Optional > Fix For: 2.0 (discussion) > > > Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should -either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or- simply return zero and don't cache the value at all. > UPDATE: We may not return a number based on the annotation type because it would break the {{java.lang.annotation.Annotation.hashCode()}} contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From arjan.tijms at gmail.com Tue Sep 13 03:46:12 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 13 Sep 2016 09:46:12 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: p.s. On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba wrote: > Stuart has a good point about backward compatibility. Servlet impl would > have to detect CDI version and skip registration if not 2.0+. I think > SERVLET_SPEC-116 should be reopened and the discussion restarted. > Would you like to re-open that discussion on the Servlet list? Would be good to have someone from the CDI EG explaining the case I think. Kind regards, Arjan Tijms > > >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> But it's more complicated then it sounds. For example, >> HttpServletRequest attibutes might be used as backing storage of the >> request context. So that it cannot simply change... >> >> Anyway, I think this problem deserves some attention from both the >> CDI and the Servlet EG. >> >> Martin >> >> Dne 8.9.2016 v 13:31 arjan tijms napsal(a): >> >> Hi, >> >> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau >> >> >> >> >> wrote: >> >> Hit that issue as well several times. >> >> It is more vicious than it looks like IMO cause CDI will >> *never* get >> *the* right request for everybody, it is as simple as that. >> Any part >> of the app can rely on the wrapper level N (of course N being >> different for each mentionned parts of the app). >> >> >> What I was thinking, but maybe I'm wrong, is that the >> application never >> "just" wraps the request and uses it for itself. It always >> passes it to >> the container, which then passes it on to the next Filter, >> Servlet, or >> whatever. So at that point the container code has the opportunity >> to >> store the request as being the "current" one. >> >> E.g. if you do: >> >> RequestDispatcher dispatcher = >> servletContext().getRequestDispatcher(...); >> dispatcher.forward(wrap(request), response); >> >> Then the RequestDispatcher, which is a container class, receives >> the >> wrapped request and can make it available. >> >> The other way around, eventually every AuthModule, Filter or >> Servlet has >> to be called by the container at some point. E.g. the "protected >> void >> service(HttpServletRequest req, HttpServletResponse resp)" is >> called by >> the container. >> >> So just before the container invokes the HttpServlet#service >> method, the >> container can store the request, and CDI (via an SPI) can pick it >> up >> from there. >> >> That way in every context you can always have the *current* >> request (the >> request that's passed in to the last Servlet or Filter call on >> the stack). >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Best CDI can do is to provide the request it has (already >> the case >> and cost pretty much nothing) and enable the user to >> produces very >> easily its own request from its filter (or equivalent) for >> its usage >> IMO - which is IMO already doable but maybe there is another >> shortcut we can introduce I didnt think about. If you look >> one step >> further any web framework built on top of CDI does it and >> therefore >> runs in a well known context. >> >> >> Romain Manni-Bucau >> @rmannibucau > > | Blog >> > > | Old Wordpress Blog >> > > | Github >> > > | LinkedIn >> > > | Tomitriber >> | JavaEE Factory >> > > >> >> 2016-09-08 13:03 GMT+02:00 arjan tijms >> >> >> >>: >> >> Hi, >> >> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >> >> >> >> >> wrote: >> >> that's a good question. In Weld, the request object is >> captured during request context activation, i.e. >> during >> ServletRequestListener.requestInitialized() >> notification and >> before any filter or servlet is invoked. So wrappers >> are >> ignored and the original/first request is used. >> >> >> Indeed, although do note that some servers (Liberty and >> WebLogic >> I think) send the >> ServletRequestListener.requestInitialized() >> notification rather late, and do that after the >> application >> already has seen the request and has had a chance to >> wrap it. >> This by itself is a separate problem. So on these >> servers, Weld >> would receive an early request but not necessarily the >> earliest. >> >> >> But TBH I don't think we can fix this easily as I'm >> not >> aware of any portable way to listen for "wrapping >> actions". >> >> >> This would have to happen with Server specific code I >> guess, >> just as Weld now requires an SPI to obtain the current >> principal >> for injection. >> >> You could say that the Servlet container could store the >> request >> "somewhere" on a stack structure, just before it invokes >> the >> ServerAuthModule, Filter, Servlet and anything else I >> may have >> forgotten, and then when control flows back to each >> Servlet, >> Filter, etc unwind that stack. >> >> At the very least the spec for now should perhaps >> clarify this? >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> Martin >> >> Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >> >> Hi, >> >> The CDI spec defines a built-in bean for the type >> HttpServletRequest. In >> 3.8 it says: >> >> "A servlet container must provide the following >> built-in >> beans, all of >> which have qualifier @Default: >> >> a bean with bean type >> javax.servlet.http.HttpServletRequest, allowing >> injection of a reference to the >> HttpServletRequest" >> >> An HttpServletRequest however can be wrapped >> multiple >> times and by >> multiple artefacts. I.e. by a ServerAuthModule, >> Filter and a >> RequestDispatcher. >> >> The question now is; which version of the >> HttpServletRequest is supposed >> to be injected? >> >> * The first one in the chain? >> * The last one in the chain? >> * The current one at a given point in the chain? >> >> A little bit of experimenting seems to indicate >> it's now >> often "one of >> the first ones", e.g. the one that happened to be >> current when e.g. a >> ServletRequestListener that initialises a >> specific CDI >> implementation is >> called. >> >> I think this is a little confusing, as working >> with an >> injected request >> can now totally ignore the request wrapping that >> has >> been done and break >> an application badly. >> >> Thoughts? >> >> Kind regards, >> Arjan Tijms >> >> >> >> _______________________________________________ >> 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. >> >> >> >> >> > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160913/0569e725/attachment-0001.html From issues at jboss.org Tue Sep 13 03:51:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 13 Sep 2016 03:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations In-Reply-To: References: Message-ID: Mark Struberg created CDI-631: --------------------------------- Summary: Improve AnnotationLiteral for empty annotations Key: CDI-631 URL: https://issues.jboss.org/browse/CDI-631 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Mark Struberg Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + + That's horrible expensive. In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members: https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/EmptyAnnotationLiteral.java The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type. We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 04:15:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 13 Sep 2016 04:15:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292307#comment-13292307 ] Mark Struberg commented on CDI-631: ----------------------------------- The other question is whether we can cache the hashCode and toString as it should not be subject to changes, right? I mean do we allow AnnotationLiteral subclasses to modify their values during runtime? That would conflict with the Annotation definition imo. > Improve AnnotationLiteral for empty annotations > ----------------------------------------------- > > Key: CDI-631 > URL: https://issues.jboss.org/browse/CDI-631 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Mark Struberg > > Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + + > That's horrible expensive. > In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members: > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/EmptyAnnotationLiteral.java > The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type. > We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 04:22:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 13 Sep 2016 04:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292316#comment-13292316 ] Martin Kouba commented on CDI-631: ---------------------------------- Well, values should not change but it's possible. There was already an attempt to improve this - see also CDI-149. > Improve AnnotationLiteral for empty annotations > ----------------------------------------------- > > Key: CDI-631 > URL: https://issues.jboss.org/browse/CDI-631 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Mark Struberg > > Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + + > That's horrible expensive. > In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members: > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/EmptyAnnotationLiteral.java > The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type. > We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From EMIJIANG at uk.ibm.com Tue Sep 13 04:37:08 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 13 Sep 2016 09:37:08 +0100 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: References: <1416404859.2581553.1473660055325@mail.yahoo.com>, <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> Message-ID: First of all, the subject line suggests the produces should be inherited under all conditions. Anyway, after your explanation, I think this suggestion contradicts with spec and breaks backward compatibility. In the cdi 1.2/cdi 2.0 spec, The only way one bean can completely override a second bean at all injection points is if it implements all the bean types and declares all the qualifiers of the second bean. However, if the second bean declares a producer method or observer method, then even this is not enough to ensure that the second bean is never called! To help prevent developer error, the first bean may: directly extend the bean class of the second bean, or directly override the producer method, in the case that the second bean is a producer method, and then explicitly declare that it specializes the second bean. After this suggestion, the above sentence is not true any more. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: Matej Novotny , Mark Struberg Cc: Emily Jiang/UK/IBM at IBMGB, cdi-dev Date: 12/09/2016 13:31 Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org @Matej - Yes, that would be consistent with what I was seeing as well. @Mark - Are you thinking about decorators and not alternatives? See also [1] Really the goal here is to substitute the bean, but not just the provided bean the producer method that it exposes. It seems to work as I would expect it in weld (as mentioned), when I add @Produces to the method, it overrides the base class's producer method. No ambiguous resolutions, it just works properly. Realistically, this is all an experiment to see if I can provide spring boot like default configurations (beans, config values, etc) in a framework, and override them as an application developer. [1]: http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#alternatives From: Matej Novotny Sent: Monday, September 12, 2016 3:28 AM To: Mark Struberg Cc: John Ament; Emily Jiang; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Hi all, I did some testing (with Weld) and it seems the scope IS inherited when you use @Alternative. However it IS NOT inherited when you use @Specialized. Not yet sure if this is intended or anyhow spec-defined, just stating facts. Matej ----- Original Message ----- > From: "Mark Struberg" > To: "John Ament" , "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, September 12, 2016 8:00:55 AM > Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > > > Right now inheritance of managed beans is itself problematic, as > > > injecting the base class can cause these ambiguous resolutions. > > Yes, that's why we originally introduced @Typed. > > > > Your sample wont work as an Alternative as it extends a concrete class and > doesn't implement any interface. > Did you mean @Specializes? > Note that with @Alternative you won't make the original producer go away.You > would also need to add @Alternative to the producer method imo. The rules > for making an alternative producer method are really a bit confusing ;) I > think the most portable way is to annotate both the class and the producer > method with @Alternative. > > > LieGrue, > strub > > > On Monday, 12 September 2016, 0:57, John Ament > wrote: > > > >Hi Emily, > > > > > >I disagree, at least it doesn't add any new ambiguous injections. The > >use-case is specifically to Specialized/Alternative beans. Right now > >inheritance of managed beans is itself problematic, as injecting the base > >class can cause these ambiguous resolutions. > > > > > >The example I sent out actually works correctly (in weld at least), really > >my propose is to remove the need to have Produces a second time and update > >the spec to clarify what happens here (FWIW, I don't believe the case is > >currently described in the spec), hopefully to say that qualifiers and > >scopes from the base method remain in effect, unless explicitly overridden. > > > > > >John > > > > > > > >________________________________ > > > >From: Emily Jiang > >Sent: Sunday, September 11, 2016 5:59 PM > >To: John Ament > >Cc: cdi-dev > >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > >I think this is very problematic as you will get > >AmbiguousResolutionException all the time once we introduce this > >inheritance. > > > >Many thanks, > >Emily > >=========================== > >Emily Jiang > >WebSphere Application Server, CDI Development Lead > > > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > >Phone: +44 (0)1962 816278 Internal: 246278 > > > >Email: emijiang at uk.ibm.com > >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > >From: John Ament > >To: cdi-dev > >Date: 11/09/2016 20:04 > >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be > >inherited? > >Sent by: cdi-dev-bounces at lists.jboss.org > >>________________________________ > > > > > > > >All, > > > >I was just thinking about alternatives and producer methods. Suppose I have > >the following bean: > > > >@ApplicationScoped > >public class Boop { > > > > @Produces > > @ApplicationScoped > > public Simpler makeSimpler() { > > return new Simpler("Boop"); > > } > >} > > > >If I want to override the producer method, I need to declare fully: > > > >@Alternative > >@Priority(100) > >@ApplicationScoped > >public class BoopAlternative extends Boop{ > > @Override > > @Produces > > public Simpler makeSimpler() { > > return new Simpler("Boop2"); > > } > >} > > > >For some reason, scopes are inherited, but the produces annotation is not. > >At least in the case of a producer method, it seems like it would be > >useful for @Produces to be inherited as well. > > > >John > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > _______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/cdi-dev cdi-dev Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > > >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 Info Page - JBoss Developer > >lists.jboss.org > >List to discuss the development of CDI (the specification) To see the > >collection of prior postings to the list, visit the cdi-dev Archives. > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with number > >741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > >_______________________________________________ > >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. > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160913/637427da/attachment-0001.html From john.ament at spartasystems.com Tue Sep 13 06:33:33 2016 From: john.ament at spartasystems.com (John Ament) Date: Tue, 13 Sep 2016 10:33:33 +0000 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: References: <1416404859.2581553.1473660055325@mail.yahoo.com>, <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> , Message-ID: Emily, Just want to make sure I follow. Are you saying this because right now it is required that you add @Produces to the overridden method? I don't realistically see a scenario where you would override the method and not add produces. This method is intended to be called by the container. John ________________________________ From: Emily Jiang Sent: Tuesday, September 13, 2016 4:37 AM To: John Ament Cc: Matej Novotny; Mark Struberg; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? First of all, the subject line suggests the produces should be inherited under all conditions. Anyway, after your explanation, I think this suggestion contradicts with spec and breaks backward compatibility. In the cdi 1.2/cdi 2.0 spec, The only way one bean can completely override a second bean at all injection points is if it implements all the bean types and declares all the qualifiers of the second bean. However, if the second bean declares a producer method or observer method, then even this is not enough to ensure that the second bean is never called! To help prevent developer error, the first bean may: * directly extend the bean class of the second bean, or * directly override the producer method, in the case that the second bean is a producer method, and then explicitly declare that it specializes the second bean. After this suggestion, the above sentence is not true any more. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: Matej Novotny , Mark Struberg Cc: Emily Jiang/UK/IBM at IBMGB, cdi-dev Date: 12/09/2016 13:31 Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org ________________________________ @Matej - Yes, that would be consistent with what I was seeing as well. @Mark - Are you thinking about decorators and not alternatives? See also [1] Really the goal here is to substitute the bean, but not just the provided bean the producer method that it exposes. It seems to work as I would expect it in weld (as mentioned), when I add @Produces to the method, it overrides the base class's producer method. No ambiguous resolutions, it just works properly. Realistically, this is all an experiment to see if I can provide spring boot like default configurations (beans, config values, etc) in a framework, and override them as an application developer. [1]: http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#alternatives ________________________________ From: Matej Novotny Sent: Monday, September 12, 2016 3:28 AM To: Mark Struberg Cc: John Ament; Emily Jiang; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Hi all, I did some testing (with Weld) and it seems the scope IS inherited when you use @Alternative. However it IS NOT inherited when you use @Specialized. Not yet sure if this is intended or anyhow spec-defined, just stating facts. Matej ----- Original Message ----- > From: "Mark Struberg" > To: "John Ament" , "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, September 12, 2016 8:00:55 AM > Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > > > Right now inheritance of managed beans is itself problematic, as > > > injecting the base class can cause these ambiguous resolutions. > > Yes, that's why we originally introduced @Typed. > > > > Your sample wont work as an Alternative as it extends a concrete class and > doesn't implement any interface. > Did you mean @Specializes? > Note that with @Alternative you won't make the original producer go away.You > would also need to add @Alternative to the producer method imo. The rules > for making an alternative producer method are really a bit confusing ;) I > think the most portable way is to annotate both the class and the producer > method with @Alternative. > > > LieGrue, > strub > > > On Monday, 12 September 2016, 0:57, John Ament > wrote: > > > >Hi Emily, > > > > > >I disagree, at least it doesn't add any new ambiguous injections. The > >use-case is specifically to Specialized/Alternative beans. Right now > >inheritance of managed beans is itself problematic, as injecting the base > >class can cause these ambiguous resolutions. > > > > > >The example I sent out actually works correctly (in weld at least), really > >my propose is to remove the need to have Produces a second time and update > >the spec to clarify what happens here (FWIW, I don't believe the case is > >currently described in the spec), hopefully to say that qualifiers and > >scopes from the base method remain in effect, unless explicitly overridden. > > > > > >John > > > > > > > >________________________________ > > > >From: Emily Jiang > >Sent: Sunday, September 11, 2016 5:59 PM > >To: John Ament > >Cc: cdi-dev > >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > >I think this is very problematic as you will get > >AmbiguousResolutionException all the time once we introduce this > >inheritance. > > > >Many thanks, > >Emily > >=========================== > >Emily Jiang > >WebSphere Application Server, CDI Development Lead > > > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > >Phone: +44 (0)1962 816278 Internal: 246278 > > > >Email: emijiang at uk.ibm.com > >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > >From: John Ament > >To: cdi-dev > >Date: 11/09/2016 20:04 > >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be > >inherited? > >Sent by: cdi-dev-bounces at lists.jboss.org > >>________________________________ > > > > > > > >All, > > > >I was just thinking about alternatives and producer methods. Suppose I have > >the following bean: > > > >@ApplicationScoped > >public class Boop { > > > > @Produces > > @ApplicationScoped > > public Simpler makeSimpler() { > > return new Simpler("Boop"); > > } > >} > > > >If I want to override the producer method, I need to declare fully: > > > >@Alternative > >@Priority(100) > >@ApplicationScoped > >public class BoopAlternative extends Boop{ > > @Override > > @Produces > > public Simpler makeSimpler() { > > return new Simpler("Boop2"); > > } > >} > > > >For some reason, scopes are inherited, but the produces annotation is not. > >At least in the case of a producer method, it seems like it would be > >useful for @Produces to be inherited as well. > > > >John > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > _______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/cdi-dev cdi-dev Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > > >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 Info Page - JBoss Developer > >lists.jboss.org > >List to discuss the development of CDI (the specification) To see the > >collection of prior postings to the list, visit the cdi-dev Archives. > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with number > >741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > >_______________________________________________ > >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. > ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160913/405449df/attachment-0001.html From tremes at redhat.com Tue Sep 13 08:51:31 2016 From: tremes at redhat.com (Tomas Remes) Date: Tue, 13 Sep 2016 08:51:31 -0400 (EDT) Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: References: <1416404859.2581553.1473660055325@mail.yahoo.com> <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> Message-ID: <1229415252.11346010.1473771091730.JavaMail.zimbra@redhat.com> Hi John, Please note there is no such inheritance of scope for producer method in this case in the Weld. I added test https://github.com/weld/core/commit/77f6916b55882a81d5fb33313d2e58806605bb17 Thanks Tom ----- Original Message ----- From: "John Ament" To: "Emily Jiang" Cc: "cdi-dev" Sent: Tuesday, September 13, 2016 12:33:33 PM Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Emily, Just want to make sure I follow. Are you saying this because right now it is required that you add @Produces to the overridden method? I don't realistically see a scenario where you would override the method and not add produces. This method is intended to be called by the container. John From: Emily Jiang Sent: Tuesday, September 13, 2016 4:37 AM To: John Ament Cc: Matej Novotny; Mark Struberg; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? First of all, the subject line suggests the produces should be inherited under all conditions. Anyway, after your explanation, I think this suggestion contradicts with spec and breaks backward compatibility. In the cdi 1.2/cdi 2.0 spec, The only way one bean can completely override a second bean at all injection points is if it implements all the bean types and declares all the qualifiers of the second bean. However, if the second bean declares a producer method or observer method, then even this is not enough to ensure that the second bean is never called! To help prevent developer error, the first bean may: * directly extend the bean class of the second bean, or * directly override the producer method, in the case that the second bean is a producer method, and then explicitly declare that it specializes the second bean. After this suggestion, the above sentence is not true any more. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: Matej Novotny , Mark Struberg Cc: Emily Jiang/UK/IBM at IBMGB, cdi-dev Date: 12/09/2016 13:31 Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org @Matej - Yes, that would be consistent with what I was seeing as well. @Mark - Are you thinking about decorators and not alternatives? See also [1] Really the goal here is to substitute the bean, but not just the provided bean the producer method that it exposes. It seems to work as I would expect it in weld (as mentioned), when I add @Produces to the method, it overrides the base class's producer method. No ambiguous resolutions, it just works properly. Realistically, this is all an experiment to see if I can provide spring boot like default configurations (beans, config values, etc) in a framework, and override them as an application developer. [1]: http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#alternatives From: Matej Novotny Sent: Monday, September 12, 2016 3:28 AM To: Mark Struberg Cc: John Ament; Emily Jiang; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Hi all, I did some testing (with Weld) and it seems the scope IS inherited when you use @Alternative. However it IS NOT inherited when you use @Specialized. Not yet sure if this is intended or anyhow spec-defined, just stating facts. Matej ----- Original Message ----- > From: "Mark Struberg" > To: "John Ament" , "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, September 12, 2016 8:00:55 AM > Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > > > Right now inheritance of managed beans is itself problematic, as > > > injecting the base class can cause these ambiguous resolutions. > > Yes, that's why we originally introduced @Typed. > > > > Your sample wont work as an Alternative as it extends a concrete class and > doesn't implement any interface. > Did you mean @Specializes? > Note that with @Alternative you won't make the original producer go away.You > would also need to add @Alternative to the producer method imo. The rules > for making an alternative producer method are really a bit confusing ;) I > think the most portable way is to annotate both the class and the producer > method with @Alternative. > > > LieGrue, > strub > > > On Monday, 12 September 2016, 0:57, John Ament > wrote: > > > >Hi Emily, > > > > > >I disagree, at least it doesn't add any new ambiguous injections. The > >use-case is specifically to Specialized/Alternative beans. Right now > >inheritance of managed beans is itself problematic, as injecting the base > >class can cause these ambiguous resolutions. > > > > > >The example I sent out actually works correctly (in weld at least), really > >my propose is to remove the need to have Produces a second time and update > >the spec to clarify what happens here (FWIW, I don't believe the case is > >currently described in the spec), hopefully to say that qualifiers and > >scopes from the base method remain in effect, unless explicitly overridden. > > > > > >John > > > > > > > >________________________________ > > > >From: Emily Jiang > >Sent: Sunday, September 11, 2016 5:59 PM > >To: John Ament > >Cc: cdi-dev > >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > >I think this is very problematic as you will get > >AmbiguousResolutionException all the time once we introduce this > >inheritance. > > > >Many thanks, > >Emily > >=========================== > >Emily Jiang > >WebSphere Application Server, CDI Development Lead > > > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > >Phone: +44 (0)1962 816278 Internal: 246278 > > > >Email: emijiang at uk.ibm.com > >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > >From: John Ament > >To: cdi-dev > >Date: 11/09/2016 20:04 > >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be > >inherited? > >Sent by: cdi-dev-bounces at lists.jboss.org > >>________________________________ > > > > > > > >All, > > > >I was just thinking about alternatives and producer methods. Suppose I have > >the following bean: > > > >@ApplicationScoped > >public class Boop { > > > > @Produces > > @ApplicationScoped > > public Simpler makeSimpler() { > > return new Simpler("Boop"); > > } > >} > > > >If I want to override the producer method, I need to declare fully: > > > >@Alternative > >@Priority(100) > >@ApplicationScoped > >public class BoopAlternative extends Boop{ > > @Override > > @Produces > > public Simpler makeSimpler() { > > return new Simpler("Boop2"); > > } > >} > > > >For some reason, scopes are inherited, but the produces annotation is not. > >At least in the case of a producer method, it seems like it would be > >useful for @Produces to be inherited as well. > > > >John > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > _______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev cdi-dev Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > > >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 Info Page - JBoss Developer > >lists.jboss.org > >List to discuss the development of CDI (the specification) To see the > >collection of prior postings to the list, visit the cdi-dev Archives. > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with number > >741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > >_______________________________________________ > >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. > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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 john.ament at spartasystems.com Tue Sep 13 09:15:51 2016 From: john.ament at spartasystems.com (John Ament) Date: Tue, 13 Sep 2016 13:15:51 +0000 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: <1229415252.11346010.1473771091730.JavaMail.zimbra@redhat.com> References: <1416404859.2581553.1473660055325@mail.yahoo.com> <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> , <1229415252.11346010.1473771091730.JavaMail.zimbra@redhat.com> Message-ID: Tomas, Yep, I'm not trying to say there is already inheritance. What I'm trying to say is that the produces annotation should be inherited, making it so that there is inheritance now. John ________________________________ From: Tomas Remes Sent: Tuesday, September 13, 2016 8:51 AM To: John Ament Cc: cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Hi John, Please note there is no such inheritance of scope for producer method in this case in the Weld. I added test https://github.com/weld/core/commit/77f6916b55882a81d5fb33313d2e58806605bb17 [https://avatars2.githubusercontent.com/u/924640?v=3&s=200] Test scope of alternative producer is not inherited. ? weld/core at 77f6916 github.com core - Weld, including integrations for Servlet containers and Java SE, examples and documentation Thanks Tom ----- Original Message ----- From: "John Ament" To: "Emily Jiang" Cc: "cdi-dev" Sent: Tuesday, September 13, 2016 12:33:33 PM Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Emily, Just want to make sure I follow. Are you saying this because right now it is required that you add @Produces to the overridden method? I don't realistically see a scenario where you would override the method and not add produces. This method is intended to be called by the container. John From: Emily Jiang Sent: Tuesday, September 13, 2016 4:37 AM To: John Ament Cc: Matej Novotny; Mark Struberg; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? First of all, the subject line suggests the produces should be inherited under all conditions. Anyway, after your explanation, I think this suggestion contradicts with spec and breaks backward compatibility. In the cdi 1.2/cdi 2.0 spec, The only way one bean can completely override a second bean at all injection points is if it implements all the bean types and declares all the qualifiers of the second bean. However, if the second bean declares a producer method or observer method, then even this is not enough to ensure that the second bean is never called! To help prevent developer error, the first bean may: * directly extend the bean class of the second bean, or * directly override the producer method, in the case that the second bean is a producer method, and then explicitly declare that it specializes the second bean. After this suggestion, the above sentence is not true any more. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: Matej Novotny , Mark Struberg Cc: Emily Jiang/UK/IBM at IBMGB, cdi-dev Date: 12/09/2016 13:31 Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org @Matej - Yes, that would be consistent with what I was seeing as well. @Mark - Are you thinking about decorators and not alternatives? See also [1] Really the goal here is to substitute the bean, but not just the provided bean the producer method that it exposes. It seems to work as I would expect it in weld (as mentioned), when I add @Produces to the method, it overrides the base class's producer method. No ambiguous resolutions, it just works properly. Realistically, this is all an experiment to see if I can provide spring boot like default configurations (beans, config values, etc) in a framework, and override them as an application developer. [1]: http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#alternatives From: Matej Novotny Sent: Monday, September 12, 2016 3:28 AM To: Mark Struberg Cc: John Ament; Emily Jiang; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Hi all, I did some testing (with Weld) and it seems the scope IS inherited when you use @Alternative. However it IS NOT inherited when you use @Specialized. Not yet sure if this is intended or anyhow spec-defined, just stating facts. Matej ----- Original Message ----- > From: "Mark Struberg" > To: "John Ament" , "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, September 12, 2016 8:00:55 AM > Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > > > Right now inheritance of managed beans is itself problematic, as > > > injecting the base class can cause these ambiguous resolutions. > > Yes, that's why we originally introduced @Typed. > > > > Your sample wont work as an Alternative as it extends a concrete class and > doesn't implement any interface. > Did you mean @Specializes? > Note that with @Alternative you won't make the original producer go away.You > would also need to add @Alternative to the producer method imo. The rules > for making an alternative producer method are really a bit confusing ;) I > think the most portable way is to annotate both the class and the producer > method with @Alternative. > > > LieGrue, > strub > > > On Monday, 12 September 2016, 0:57, John Ament > wrote: > > > >Hi Emily, > > > > > >I disagree, at least it doesn't add any new ambiguous injections. The > >use-case is specifically to Specialized/Alternative beans. Right now > >inheritance of managed beans is itself problematic, as injecting the base > >class can cause these ambiguous resolutions. > > > > > >The example I sent out actually works correctly (in weld at least), really > >my propose is to remove the need to have Produces a second time and update > >the spec to clarify what happens here (FWIW, I don't believe the case is > >currently described in the spec), hopefully to say that qualifiers and > >scopes from the base method remain in effect, unless explicitly overridden. > > > > > >John > > > > > > > >________________________________ > > > >From: Emily Jiang > >Sent: Sunday, September 11, 2016 5:59 PM > >To: John Ament > >Cc: cdi-dev > >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > >I think this is very problematic as you will get > >AmbiguousResolutionException all the time once we introduce this > >inheritance. > > > >Many thanks, > >Emily > >=========================== > >Emily Jiang > >WebSphere Application Server, CDI Development Lead > > > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > >Phone: +44 (0)1962 816278 Internal: 246278 > > > >Email: emijiang at uk.ibm.com > >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > >From: John Ament > >To: cdi-dev > >Date: 11/09/2016 20:04 > >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be > >inherited? > >Sent by: cdi-dev-bounces at lists.jboss.org > >>________________________________ > > > > > > > >All, > > > >I was just thinking about alternatives and producer methods. Suppose I have > >the following bean: > > > >@ApplicationScoped > >public class Boop { > > > > @Produces > > @ApplicationScoped > > public Simpler makeSimpler() { > > return new Simpler("Boop"); > > } > >} > > > >If I want to override the producer method, I need to declare fully: > > > >@Alternative > >@Priority(100) > >@ApplicationScoped > >public class BoopAlternative extends Boop{ > > @Override > > @Produces > > public Simpler makeSimpler() { > > return new Simpler("Boop2"); > > } > >} > > > >For some reason, scopes are inherited, but the produces annotation is not. > >At least in the case of a producer method, it seems like it would be > >useful for @Produces to be inherited as well. > > > >John > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > _______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev cdi-dev Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > > >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 Info Page - JBoss Developer > >lists.jboss.org > >List to discuss the development of CDI (the specification) To see the > >collection of prior postings to the list, visit the cdi-dev Archives. > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with number > >741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > >_______________________________________________ > >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. > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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 ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160913/de2f9e23/attachment-0001.html From EMIJIANG at uk.ibm.com Tue Sep 13 09:34:07 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 13 Sep 2016 14:34:07 +0100 Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? In-Reply-To: References: <1416404859.2581553.1473660055325@mail.yahoo.com>, <82375909.6581150.1473665297829.JavaMail.zimbra@redhat.com> , Message-ID: John, Basically what you suggested is to omit the @Produces on overriding the producer methods. I am trying to spell out the gap: I am not sure whether the user scenario, where you would override the method but not adding @Produces, is useful. Is this potentially used by any testing apps? If you don't add @Produces on overriding a producer method, when the container calls the producer method, which one will be invoked? Something related to this area, for the following two code snippets, the first producer is a kind of alternative even though not annotating with @Alternative. They are the same, right? @Alternative @Priority(100) @ApplicationScoped public class BoopAlternative extends Boop{ @Override @Produces public Simpler makeSimpler() { return new Simpler("Boop2"); } @Alternative @Priority(100) @ApplicationScoped public class BoopAlternative extends Boop{ @Override @Produces @Alternative public Simpler makeSimpler() { return new Simpler("Boop2"); } Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: Emily Jiang/UK/IBM at IBMGB Cc: cdi-dev Date: 13/09/2016 11:38 Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org Emily, Just want to make sure I follow. Are you saying this because right now it is required that you add @Produces to the overridden method? I don't realistically see a scenario where you would override the method and not add produces. This method is intended to be called by the container. John From: Emily Jiang Sent: Tuesday, September 13, 2016 4:37 AM To: John Ament Cc: Matej Novotny; Mark Struberg; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? First of all, the subject line suggests the produces should be inherited under all conditions. Anyway, after your explanation, I think this suggestion contradicts with spec and breaks backward compatibility. In the cdi 1.2/cdi 2.0 spec, The only way one bean can completely override a second bean at all injection points is if it implements all the bean types and declares all the qualifiers of the second bean. However, if the second bean declares a producer method or observer method, then even this is not enough to ensure that the second bean is never called! To help prevent developer error, the first bean may: directly extend the bean class of the second bean, or directly override the producer method, in the case that the second bean is a producer method, and then explicitly declare that it specializes the second bean. After this suggestion, the above sentence is not true any more. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: John Ament To: Matej Novotny , Mark Struberg Cc: Emily Jiang/UK/IBM at IBMGB, cdi-dev Date: 12/09/2016 13:31 Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Sent by: cdi-dev-bounces at lists.jboss.org @Matej - Yes, that would be consistent with what I was seeing as well. @Mark - Are you thinking about decorators and not alternatives? See also [1] Really the goal here is to substitute the bean, but not just the provided bean the producer method that it exposes. It seems to work as I would expect it in weld (as mentioned), when I add @Produces to the method, it overrides the base class's producer method. No ambiguous resolutions, it just works properly. Realistically, this is all an experiment to see if I can provide spring boot like default configurations (beans, config values, etc) in a framework, and override them as an application developer. [1]: http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#alternatives From: Matej Novotny Sent: Monday, September 12, 2016 3:28 AM To: Mark Struberg Cc: John Ament; Emily Jiang; cdi-dev Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? Hi all, I did some testing (with Weld) and it seems the scope IS inherited when you use @Alternative. However it IS NOT inherited when you use @Specialized. Not yet sure if this is intended or anyhow spec-defined, just stating facts. Matej ----- Original Message ----- > From: "Mark Struberg" > To: "John Ament" , "Emily Jiang" > Cc: "cdi-dev" > Sent: Monday, September 12, 2016 8:00:55 AM > Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > > > Right now inheritance of managed beans is itself problematic, as > > > injecting the base class can cause these ambiguous resolutions. > > Yes, that's why we originally introduced @Typed. > > > > Your sample wont work as an Alternative as it extends a concrete class and > doesn't implement any interface. > Did you mean @Specializes? > Note that with @Alternative you won't make the original producer go away.You > would also need to add @Alternative to the producer method imo. The rules > for making an alternative producer method are really a bit confusing ;) I > think the most portable way is to annotate both the class and the producer > method with @Alternative. > > > LieGrue, > strub > > > On Monday, 12 September 2016, 0:57, John Ament > wrote: > > > >Hi Emily, > > > > > >I disagree, at least it doesn't add any new ambiguous injections. The > >use-case is specifically to Specialized/Alternative beans. Right now > >inheritance of managed beans is itself problematic, as injecting the base > >class can cause these ambiguous resolutions. > > > > > >The example I sent out actually works correctly (in weld at least), really > >my propose is to remove the need to have Produces a second time and update > >the spec to clarify what happens here (FWIW, I don't believe the case is > >currently described in the spec), hopefully to say that qualifiers and > >scopes from the base method remain in effect, unless explicitly overridden. > > > > > >John > > > > > > > >________________________________ > > > >From: Emily Jiang > >Sent: Sunday, September 11, 2016 5:59 PM > >To: John Ament > >Cc: cdi-dev > >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited? > > > >I think this is very problematic as you will get > >AmbiguousResolutionException all the time once we introduce this > >inheritance. > > > >Many thanks, > >Emily > >=========================== > >Emily Jiang > >WebSphere Application Server, CDI Development Lead > > > >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > >Phone: +44 (0)1962 816278 Internal: 246278 > > > >Email: emijiang at uk.ibm.com > >Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > > > > > > > > >From: John Ament > >To: cdi-dev > >Date: 11/09/2016 20:04 > >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be > >inherited? > >Sent by: cdi-dev-bounces at lists.jboss.org > >>________________________________ > > > > > > > >All, > > > >I was just thinking about alternatives and producer methods. Suppose I have > >the following bean: > > > >@ApplicationScoped > >public class Boop { > > > > @Produces > > @ApplicationScoped > > public Simpler makeSimpler() { > > return new Simpler("Boop"); > > } > >} > > > >If I want to override the producer method, I need to declare fully: > > > >@Alternative > >@Priority(100) > >@ApplicationScoped > >public class BoopAlternative extends Boop{ > > @Override > > @Produces > > public Simpler makeSimpler() { > > return new Simpler("Boop2"); > > } > >} > > > >For some reason, scopes are inherited, but the produces annotation is not. > >At least in the case of a producer method, it seems like it would be > >useful for @Produces to be inherited as well. > > > >John > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > _______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/cdi-dev cdi-dev Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > > >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 Info Page - JBoss Developer > >lists.jboss.org > >List to discuss the development of CDI (the specification) To see the > >collection of prior postings to the list, visit the cdi-dev Archives. > > > > > >Unless stated otherwise above: > >IBM United Kingdom Limited - Registered in England and Wales with number > >741598. > >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > >________________________________ > > NOTICE: This e-mail message and any attachments may contain confidential, > > proprietary, and/or privileged information which should be treated > > accordingly. If you are not the intended recipient, please notify the > > sender immediately by return e-mail, delete this message, and destroy all > > physical and electronic copies. Thank you. > > > >_______________________________________________ > >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. > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. _______________________________________________ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160913/2cec0a3a/attachment-0001.html From mkouba at redhat.com Tue Sep 13 09:40:37 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 13 Sep 2016 15:40:37 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> Message-ID: <59694418-7def-082e-bfd6-76736cb4f078@redhat.com> Dne 13.9.2016 v 09:46 arjan tijms napsal(a): > p.s. > > On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba > wrote: > > Stuart has a good point about backward compatibility. Servlet impl > would have to detect CDI version and skip registration if not 2.0+. > I think SERVLET_SPEC-116 should be reopened and the discussion > restarted. > > > Would you like to re-open that discussion on the Servlet list? Would be > good to have someone from the CDI EG explaining the case I think. Yes, that would be good. Antoine, you could meet some Servlet EG members on J1 and discuss the topic over a beer ;-) > > Kind regards, > Arjan Tijms > > > > > > Kind regards, > Arjan Tijms > > > > > > > But it's more complicated then it sounds. For example, > HttpServletRequest attibutes might be used as backing > storage of the > request context. So that it cannot simply change... > > Anyway, I think this problem deserves some attention from > both the > CDI and the Servlet EG. > > Martin > > Dne 8.9.2016 v 13:31 arjan tijms napsal(a): > > Hi, > > On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau > > > > >>> > > wrote: > > Hit that issue as well several times. > > It is more vicious than it looks like IMO cause CDI will > *never* get > *the* right request for everybody, it is as simple > as that. > Any part > of the app can rely on the wrapper level N (of > course N being > different for each mentionned parts of the app). > > > What I was thinking, but maybe I'm wrong, is that the > application never > "just" wraps the request and uses it for itself. It always > passes it to > the container, which then passes it on to the next Filter, > Servlet, or > whatever. So at that point the container code has the > opportunity to > store the request as being the "current" one. > > E.g. if you do: > > RequestDispatcher dispatcher = > servletContext().getRequestDispatcher(...); > dispatcher.forward(wrap(request), response); > > Then the RequestDispatcher, which is a container class, > receives the > wrapped request and can make it available. > > The other way around, eventually every AuthModule, Filter or > Servlet has > to be called by the container at some point. E.g. the > "protected > void > service(HttpServletRequest req, HttpServletResponse > resp)" is > called by > the container. > > So just before the container invokes the HttpServlet#service > method, the > container can store the request, and CDI (via an SPI) > can pick it up > from there. > > That way in every context you can always have the *current* > request (the > request that's passed in to the last Servlet or Filter > call on > the stack). > > Kind regards, > Arjan Tijms > > > > > > > > > > > > > > > > Best CDI can do is to provide the request it has > (already > the case > and cost pretty much nothing) and enable the user to > produces very > easily its own request from its filter (or > equivalent) for > its usage > IMO - which is IMO already doable but maybe there is > another > shortcut we can introduce I didnt think about. If > you look > one step > further any web framework built on top of CDI does > it and > therefore > runs in a well known context. > > > Romain Manni-Bucau > @rmannibucau > >> | Blog > > >> | Old Wordpress Blog > > >> | Github > > >> | LinkedIn > > >> | Tomitriber > | JavaEE Factory > > >> > > 2016-09-08 13:03 GMT+02:00 arjan tijms > > > > >>>: > > Hi, > > On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba > > > > >>> > > wrote: > > that's a good question. In Weld, the request > object is > captured during request context activation, > i.e. during > ServletRequestListener.requestInitialized() > notification and > before any filter or servlet is invoked. So > wrappers are > ignored and the original/first request is used. > > > Indeed, although do note that some servers > (Liberty and > WebLogic > I think) send the > ServletRequestListener.requestInitialized() > notification rather late, and do that after the > application > already has seen the request and has had a chance to > wrap it. > This by itself is a separate problem. So on these > servers, Weld > would receive an early request but not > necessarily the > earliest. > > > But TBH I don't think we can fix this easily > as I'm not > aware of any portable way to listen for > "wrapping > actions". > > > This would have to happen with Server specific > code I guess, > just as Weld now requires an SPI to obtain the > current > principal > for injection. > > You could say that the Servlet container could > store the > request > "somewhere" on a stack structure, just before it > invokes the > ServerAuthModule, Filter, Servlet and anything > else I > may have > forgotten, and then when control flows back to > each Servlet, > Filter, etc unwind that stack. > > At the very least the spec for now should perhaps > clarify this? > > Kind regards, > Arjan Tijms > > > > > > Martin > > Dne 8.9.2016 v 11:02 arjan tijms napsal(a): > > Hi, > > The CDI spec defines a built-in bean for > the type > HttpServletRequest. In > 3.8 it says: > > "A servlet container must provide the > following > built-in > beans, all of > which have qualifier @Default: > > a bean with bean type > javax.servlet.http.HttpServletRequest, > allowing > injection of a reference to the > HttpServletRequest" > > An HttpServletRequest however can be wrapped > multiple > times and by > multiple artefacts. I.e. by a > ServerAuthModule, > Filter and a > RequestDispatcher. > > The question now is; which version of the > HttpServletRequest is supposed > to be injected? > > * The first one in the chain? > * The last one in the chain? > * The current one at a given point in > the chain? > > A little bit of experimenting seems to > indicate > it's now > often "one of > the first ones", e.g. the one that > happened to be > current when e.g. a > ServletRequestListener that initialises a > specific CDI > implementation is > called. > > I think this is a little confusing, as > working > with an > injected request > can now totally ignore the request > wrapping that has > been done and break > an application badly. > > Thoughts? > > Kind regards, > Arjan Tijms > > > > > _______________________________________________ > 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. > > > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > -- Martin Kouba Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Tue Sep 13 10:37:33 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 13 Sep 2016 14:37:33 +0000 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: <59694418-7def-082e-bfd6-76736cb4f078@redhat.com> References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> <59694418-7def-082e-bfd6-76736cb4f078@redhat.com> Message-ID: Hi guys, I'd be more than happy to convince our friends of the Servlet spec to re-open this ticket. I'll talk with Ed next week. All the input you can give me to answer their objection are welcome. Antoine Le mar. 13 sept. 2016 ? 15:40, Martin Kouba a ?crit : > Dne 13.9.2016 v 09:46 arjan tijms napsal(a): > > p.s. > > > > On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba > > wrote: > > > > Stuart has a good point about backward compatibility. Servlet impl > > would have to detect CDI version and skip registration if not 2.0+. > > I think SERVLET_SPEC-116 should be reopened and the discussion > > restarted. > > > > > > Would you like to re-open that discussion on the Servlet list? Would be > > good to have someone from the CDI EG explaining the case I think. > > Yes, that would be good. Antoine, you could meet some Servlet EG members > on J1 and discuss the topic over a beer ;-) > > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > > > But it's more complicated then it sounds. For example, > > HttpServletRequest attibutes might be used as backing > > storage of the > > request context. So that it cannot simply change... > > > > Anyway, I think this problem deserves some attention from > > both the > > CDI and the Servlet EG. > > > > Martin > > > > Dne 8.9.2016 v 13:31 arjan tijms napsal(a): > > > > Hi, > > > > On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau > > > > > > > > > >>> > > > > wrote: > > > > Hit that issue as well several times. > > > > It is more vicious than it looks like IMO cause CDI > will > > *never* get > > *the* right request for everybody, it is as simple > > as that. > > Any part > > of the app can rely on the wrapper level N (of > > course N being > > different for each mentionned parts of the app). > > > > > > What I was thinking, but maybe I'm wrong, is that the > > application never > > "just" wraps the request and uses it for itself. It > always > > passes it to > > the container, which then passes it on to the next > Filter, > > Servlet, or > > whatever. So at that point the container code has the > > opportunity to > > store the request as being the "current" one. > > > > E.g. if you do: > > > > RequestDispatcher dispatcher = > > servletContext().getRequestDispatcher(...); > > dispatcher.forward(wrap(request), response); > > > > Then the RequestDispatcher, which is a container class, > > receives the > > wrapped request and can make it available. > > > > The other way around, eventually every AuthModule, > Filter or > > Servlet has > > to be called by the container at some point. E.g. the > > "protected > > void > > service(HttpServletRequest req, HttpServletResponse > > resp)" is > > called by > > the container. > > > > So just before the container invokes the > HttpServlet#service > > method, the > > container can store the request, and CDI (via an SPI) > > can pick it up > > from there. > > > > That way in every context you can always have the > *current* > > request (the > > request that's passed in to the last Servlet or Filter > > call on > > the stack). > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best CDI can do is to provide the request it has > > (already > > the case > > and cost pretty much nothing) and enable the user to > > produces very > > easily its own request from its filter (or > > equivalent) for > > its usage > > IMO - which is IMO already doable but maybe there is > > another > > shortcut we can introduce I didnt think about. If > > you look > > one step > > further any web framework built on top of CDI does > > it and > > therefore > > runs in a well known context. > > > > > > Romain Manni-Bucau > > @rmannibucau > > > > >> | Blog > > > > > > >> | Old Wordpress Blog > > > > > > >> | Github > > > > > > >> | LinkedIn > > > > > > >> | Tomitriber > > | JavaEE Factory > > > > > > >> > > > > 2016-09-08 13:03 GMT+02:00 arjan tijms > > > > > > > > > >>>: > > > > Hi, > > > > On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba > > > > > > > > > >>> > > > > wrote: > > > > that's a good question. In Weld, the request > > object is > > captured during request context activation, > > i.e. during > > ServletRequestListener.requestInitialized() > > notification and > > before any filter or servlet is invoked. So > > wrappers are > > ignored and the original/first request is > used. > > > > > > Indeed, although do note that some servers > > (Liberty and > > WebLogic > > I think) send the > > ServletRequestListener.requestInitialized() > > notification rather late, and do that after the > > application > > already has seen the request and has had a > chance to > > wrap it. > > This by itself is a separate problem. So on these > > servers, Weld > > would receive an early request but not > > necessarily the > > earliest. > > > > > > But TBH I don't think we can fix this easily > > as I'm not > > aware of any portable way to listen for > > "wrapping > > actions". > > > > > > This would have to happen with Server specific > > code I guess, > > just as Weld now requires an SPI to obtain the > > current > > principal > > for injection. > > > > You could say that the Servlet container could > > store the > > request > > "somewhere" on a stack structure, just before it > > invokes the > > ServerAuthModule, Filter, Servlet and anything > > else I > > may have > > forgotten, and then when control flows back to > > each Servlet, > > Filter, etc unwind that stack. > > > > At the very least the spec for now should perhaps > > clarify this? > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > Martin > > > > Dne 8.9.2016 v 11:02 arjan tijms napsal(a): > > > > Hi, > > > > The CDI spec defines a built-in bean for > > the type > > HttpServletRequest. In > > 3.8 it says: > > > > "A servlet container must provide the > > following > > built-in > > beans, all of > > which have qualifier @Default: > > > > a bean with bean type > > javax.servlet.http.HttpServletRequest, > > allowing > > injection of a reference to the > > HttpServletRequest" > > > > An HttpServletRequest however can be > wrapped > > multiple > > times and by > > multiple artefacts. I.e. by a > > ServerAuthModule, > > Filter and a > > RequestDispatcher. > > > > The question now is; which version of the > > HttpServletRequest is supposed > > to be injected? > > > > * The first one in the chain? > > * The last one in the chain? > > * The current one at a given point in > > the chain? > > > > A little bit of experimenting seems to > > indicate > > it's now > > often "one of > > the first ones", e.g. the one that > > happened to be > > current when e.g. a > > ServletRequestListener that initialises a > > specific CDI > > implementation is > > called. > > > > I think this is a little confusing, as > > working > > with an > > injected request > > can now totally ignore the request > > wrapping that has > > been done and break > > an application badly. > > > > Thoughts? > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > _______________________________________________ > > 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. > > > > > > > > > > > > -- > > Martin Kouba > > Software Engineer > > Red Hat, Czech Republic > > > > > > -- > 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/20160913/d481e8cb/attachment-0001.html From arjan.tijms at gmail.com Tue Sep 13 10:56:09 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 13 Sep 2016 16:56:09 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> <59694418-7def-082e-bfd6-76736cb4f078@redhat.com> Message-ID: Hi, On Tue, Sep 13, 2016 at 4:37 PM, Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > I'd be more than happy to convince our friends of the Servlet spec to > re-open this ticket. I'll talk with Ed next week. > All the input you can give me to answer their objection are welcome. > The most problematic objection IMHO was this one: GW> More over, GW> I'm concerned that by making CDI to servlet mapping a responsibility GW> of the servlet container, then we are going to have to do a GW> container to CDI adaptation for every CDI implementation out there. Ed called among others this one an "excellent point". But it's simply not true. In no version of what's being asked is there any "container to CDI adaptation for every CDI implementation out there". Extensions are portable in CDI, as you of course know. "CDI to servlet mapping" also makes me wonder if it's fully understood what was being asked, which is essentially a portable extension that registers a Bean. Perhaps helping in taking any further objections away is the fact that one of the oldest, lowest level and arguably most conservative specs out there (JTA), did something quite similar. Implementations provide a small extension that registers an interceptor and a scope. The existence of this extension does not hurt nor influence JTA is situations where CDI is not used. Backwards compatibility (in non EE environments) should be taken into account as Stuart mentioned. I.e. if an application that bundles CDI 1.x is run on a Servlet 4 container. For Java EE environments it's not an issue. Kind regards, Arjan Tijms > > Antoine > > Le mar. 13 sept. 2016 ? 15:40, Martin Kouba a ?crit : > >> Dne 13.9.2016 v 09:46 arjan tijms napsal(a): >> > p.s. >> > >> > On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba > > > wrote: >> > >> > Stuart has a good point about backward compatibility. Servlet impl >> > would have to detect CDI version and skip registration if not 2.0+. >> > I think SERVLET_SPEC-116 should be reopened and the discussion >> > restarted. >> > >> > >> > Would you like to re-open that discussion on the Servlet list? Would be >> > good to have someone from the CDI EG explaining the case I think. >> >> Yes, that would be good. Antoine, you could meet some Servlet EG members >> on J1 and discuss the topic over a beer ;-) >> >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > >> > >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > >> > >> > >> > >> > But it's more complicated then it sounds. For example, >> > HttpServletRequest attibutes might be used as backing >> > storage of the >> > request context. So that it cannot simply change... >> > >> > Anyway, I think this problem deserves some attention from >> > both the >> > CDI and the Servlet EG. >> > >> > Martin >> > >> > Dne 8.9.2016 v 13:31 arjan tijms napsal(a): >> > >> > Hi, >> > >> > On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau >> > >> > > >> > > > > > >>> >> > >> > wrote: >> > >> > Hit that issue as well several times. >> > >> > It is more vicious than it looks like IMO cause CDI >> will >> > *never* get >> > *the* right request for everybody, it is as simple >> > as that. >> > Any part >> > of the app can rely on the wrapper level N (of >> > course N being >> > different for each mentionned parts of the app). >> > >> > >> > What I was thinking, but maybe I'm wrong, is that the >> > application never >> > "just" wraps the request and uses it for itself. It >> always >> > passes it to >> > the container, which then passes it on to the next >> Filter, >> > Servlet, or >> > whatever. So at that point the container code has the >> > opportunity to >> > store the request as being the "current" one. >> > >> > E.g. if you do: >> > >> > RequestDispatcher dispatcher = >> > servletContext().getRequestDispatcher(...); >> > dispatcher.forward(wrap(request), response); >> > >> > Then the RequestDispatcher, which is a container class, >> > receives the >> > wrapped request and can make it available. >> > >> > The other way around, eventually every AuthModule, >> Filter or >> > Servlet has >> > to be called by the container at some point. E.g. the >> > "protected >> > void >> > service(HttpServletRequest req, HttpServletResponse >> > resp)" is >> > called by >> > the container. >> > >> > So just before the container invokes the >> HttpServlet#service >> > method, the >> > container can store the request, and CDI (via an SPI) >> > can pick it up >> > from there. >> > >> > That way in every context you can always have the >> *current* >> > request (the >> > request that's passed in to the last Servlet or Filter >> > call on >> > the stack). >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Best CDI can do is to provide the request it has >> > (already >> > the case >> > and cost pretty much nothing) and enable the user to >> > produces very >> > easily its own request from its filter (or >> > equivalent) for >> > its usage >> > IMO - which is IMO already doable but maybe there is >> > another >> > shortcut we can introduce I didnt think about. If >> > you look >> > one step >> > further any web framework built on top of CDI does >> > it and >> > therefore >> > runs in a well known context. >> > >> > >> > Romain Manni-Bucau >> > @rmannibucau > > >> > > > >> | Blog >> > > > >> > > > >> | Old Wordpress Blog >> > > > >> > > > >> | Github >> > > > >> > > > >> | LinkedIn >> > > > >> > > > >> | Tomitriber >> > | JavaEE Factory >> > > > >> > > > >> >> > >> > 2016-09-08 13:03 GMT+02:00 arjan tijms >> > >> > > >> > > > > > >>>: >> > >> > Hi, >> > >> > On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >> > >> > > >> > > > > > >>> >> > >> > wrote: >> > >> > that's a good question. In Weld, the request >> > object is >> > captured during request context activation, >> > i.e. during >> > ServletRequestListener.requestInitialized() >> > notification and >> > before any filter or servlet is invoked. So >> > wrappers are >> > ignored and the original/first request is >> used. >> > >> > >> > Indeed, although do note that some servers >> > (Liberty and >> > WebLogic >> > I think) send the >> > ServletRequestListener.requestInitialized() >> > notification rather late, and do that after the >> > application >> > already has seen the request and has had a >> chance to >> > wrap it. >> > This by itself is a separate problem. So on >> these >> > servers, Weld >> > would receive an early request but not >> > necessarily the >> > earliest. >> > >> > >> > But TBH I don't think we can fix this easily >> > as I'm not >> > aware of any portable way to listen for >> > "wrapping >> > actions". >> > >> > >> > This would have to happen with Server specific >> > code I guess, >> > just as Weld now requires an SPI to obtain the >> > current >> > principal >> > for injection. >> > >> > You could say that the Servlet container could >> > store the >> > request >> > "somewhere" on a stack structure, just before it >> > invokes the >> > ServerAuthModule, Filter, Servlet and anything >> > else I >> > may have >> > forgotten, and then when control flows back to >> > each Servlet, >> > Filter, etc unwind that stack. >> > >> > At the very least the spec for now should >> perhaps >> > clarify this? >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > >> > >> > >> > Martin >> > >> > Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >> > >> > Hi, >> > >> > The CDI spec defines a built-in bean for >> > the type >> > HttpServletRequest. In >> > 3.8 it says: >> > >> > "A servlet container must provide the >> > following >> > built-in >> > beans, all of >> > which have qualifier @Default: >> > >> > a bean with bean type >> > javax.servlet.http.HttpServletRequest, >> > allowing >> > injection of a reference to the >> > HttpServletRequest" >> > >> > An HttpServletRequest however can be >> wrapped >> > multiple >> > times and by >> > multiple artefacts. I.e. by a >> > ServerAuthModule, >> > Filter and a >> > RequestDispatcher. >> > >> > The question now is; which version of >> the >> > HttpServletRequest is supposed >> > to be injected? >> > >> > * The first one in the chain? >> > * The last one in the chain? >> > * The current one at a given point in >> > the chain? >> > >> > A little bit of experimenting seems to >> > indicate >> > it's now >> > often "one of >> > the first ones", e.g. the one that >> > happened to be >> > current when e.g. a >> > ServletRequestListener that initialises >> a >> > specific CDI >> > implementation is >> > called. >> > >> > I think this is a little confusing, as >> > working >> > with an >> > injected request >> > can now totally ignore the request >> > wrapping that has >> > been done and break >> > an application badly. >> > >> > Thoughts? >> > >> > Kind regards, >> > Arjan Tijms >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> > > org >> > > >> > > > > 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 >> > >> > > > > >> > > 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 >> > >> > >> >> -- >> 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/20160913/37c9f16d/attachment-0001.html From rmannibucau at gmail.com Tue Sep 13 11:01:49 2016 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Tue, 13 Sep 2016 17:01:49 +0200 Subject: [cdi-dev] Which version of HttpServletRequest is injected? In-Reply-To: References: <4def714e-4cd5-4068-2af2-c4fef74f711e@redhat.com> <59694418-7def-082e-bfd6-76736cb4f078@redhat.com> Message-ID: think that if CDI (as a spec) can extract a "servlet tck" and weld and/or OWB a quick impl of that, it would help servlet containers to see what it would look like. Does that sound feasable? Then we could point out jaxrs, bean validation, jpa, etc as doing it. Romain Manni-Bucau @rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | Tomitriber | JavaEE Factory 2016-09-13 16:56 GMT+02:00 arjan tijms : > Hi, > > On Tue, Sep 13, 2016 at 4:37 PM, Antoine Sabot-Durand < > antoine at sabot-durand.net> wrote: > >> I'd be more than happy to convince our friends of the Servlet spec to >> re-open this ticket. I'll talk with Ed next week. >> All the input you can give me to answer their objection are welcome. >> > > The most problematic objection IMHO was this one: > > GW> More over, > GW> I'm concerned that by making CDI to servlet mapping a responsibility > GW> of the servlet container, then we are going to have to do a > GW> container to CDI adaptation for every CDI implementation out there. > > Ed called among others this one an "excellent point". > > But it's simply not true. In no version of what's being asked is there any > "container to CDI adaptation for every CDI implementation out there". > Extensions are portable in CDI, as you of course know. > > "CDI to servlet mapping" also makes me wonder if it's fully understood > what was being asked, which is essentially a portable extension that > registers a Bean. > > Perhaps helping in taking any further objections away is the fact that one > of the oldest, lowest level and arguably most conservative specs out there > (JTA), did something quite similar. Implementations provide a small > extension that registers an interceptor and a scope. The existence of this > extension does not hurt nor influence JTA is situations where CDI is not > used. > > Backwards compatibility (in non EE environments) should be taken into > account as Stuart mentioned. I.e. if an application that bundles CDI 1.x is > run on a Servlet 4 container. For Java EE environments it's not an issue. > > Kind regards, > Arjan Tijms > > > > > > > > > > >> >> Antoine >> >> Le mar. 13 sept. 2016 ? 15:40, Martin Kouba a ?crit : >> >>> Dne 13.9.2016 v 09:46 arjan tijms napsal(a): >>> > p.s. >>> > >>> > On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba >> > > wrote: >>> > >>> > Stuart has a good point about backward compatibility. Servlet impl >>> > would have to detect CDI version and skip registration if not 2.0+. >>> > I think SERVLET_SPEC-116 should be reopened and the discussion >>> > restarted. >>> > >>> > >>> > Would you like to re-open that discussion on the Servlet list? Would be >>> > good to have someone from the CDI EG explaining the case I think. >>> >>> Yes, that would be good. Antoine, you could meet some Servlet EG members >>> on J1 and discuss the topic over a beer ;-) >>> >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > >>> > >>> > >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > >>> > >>> > >>> > >>> > >>> > But it's more complicated then it sounds. For example, >>> > HttpServletRequest attibutes might be used as backing >>> > storage of the >>> > request context. So that it cannot simply change... >>> > >>> > Anyway, I think this problem deserves some attention from >>> > both the >>> > CDI and the Servlet EG. >>> > >>> > Martin >>> > >>> > Dne 8.9.2016 v 13:31 arjan tijms napsal(a): >>> > >>> > Hi, >>> > >>> > On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau >>> > >>> > > >>> > >> > >> > >>> >>> > >>> > wrote: >>> > >>> > Hit that issue as well several times. >>> > >>> > It is more vicious than it looks like IMO cause >>> CDI will >>> > *never* get >>> > *the* right request for everybody, it is as simple >>> > as that. >>> > Any part >>> > of the app can rely on the wrapper level N (of >>> > course N being >>> > different for each mentionned parts of the app). >>> > >>> > >>> > What I was thinking, but maybe I'm wrong, is that the >>> > application never >>> > "just" wraps the request and uses it for itself. It >>> always >>> > passes it to >>> > the container, which then passes it on to the next >>> Filter, >>> > Servlet, or >>> > whatever. So at that point the container code has the >>> > opportunity to >>> > store the request as being the "current" one. >>> > >>> > E.g. if you do: >>> > >>> > RequestDispatcher dispatcher = >>> > servletContext().getRequestDispatcher(...); >>> > dispatcher.forward(wrap(request), response); >>> > >>> > Then the RequestDispatcher, which is a container class, >>> > receives the >>> > wrapped request and can make it available. >>> > >>> > The other way around, eventually every AuthModule, >>> Filter or >>> > Servlet has >>> > to be called by the container at some point. E.g. the >>> > "protected >>> > void >>> > service(HttpServletRequest req, HttpServletResponse >>> > resp)" is >>> > called by >>> > the container. >>> > >>> > So just before the container invokes the >>> HttpServlet#service >>> > method, the >>> > container can store the request, and CDI (via an SPI) >>> > can pick it up >>> > from there. >>> > >>> > That way in every context you can always have the >>> *current* >>> > request (the >>> > request that's passed in to the last Servlet or Filter >>> > call on >>> > the stack). >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > Best CDI can do is to provide the request it has >>> > (already >>> > the case >>> > and cost pretty much nothing) and enable the user >>> to >>> > produces very >>> > easily its own request from its filter (or >>> > equivalent) for >>> > its usage >>> > IMO - which is IMO already doable but maybe there >>> is >>> > another >>> > shortcut we can introduce I didnt think about. If >>> > you look >>> > one step >>> > further any web framework built on top of CDI does >>> > it and >>> > therefore >>> > runs in a well known context. >>> > >>> > >>> > Romain Manni-Bucau >>> > @rmannibucau >> > >>> > >> > >> | Blog >>> > >> > >>> > >> > >> | Old Wordpress Blog >>> > >> > >>> > >> > >> | Github >>> > >> > >>> > >> > >> | LinkedIn >>> > >> > >>> > >> > >> | Tomitriber >>> > | JavaEE Factory >>> > >> > >>> > >> > >> >>> > >>> > 2016-09-08 13:03 GMT+02:00 arjan tijms >>> > >>> > > >>> > >> > >> > >>>: >>> > >>> > Hi, >>> > >>> > On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba >>> > >>> > > >>> > >> > >> > >>> >>> > >>> > wrote: >>> > >>> > that's a good question. In Weld, the >>> request >>> > object is >>> > captured during request context activation, >>> > i.e. during >>> > ServletRequestListener.reques >>> tInitialized() >>> > notification and >>> > before any filter or servlet is invoked. So >>> > wrappers are >>> > ignored and the original/first request is >>> used. >>> > >>> > >>> > Indeed, although do note that some servers >>> > (Liberty and >>> > WebLogic >>> > I think) send the >>> > ServletRequestListener.requestInitialized() >>> > notification rather late, and do that after the >>> > application >>> > already has seen the request and has had a >>> chance to >>> > wrap it. >>> > This by itself is a separate problem. So on >>> these >>> > servers, Weld >>> > would receive an early request but not >>> > necessarily the >>> > earliest. >>> > >>> > >>> > But TBH I don't think we can fix this >>> easily >>> > as I'm not >>> > aware of any portable way to listen for >>> > "wrapping >>> > actions". >>> > >>> > >>> > This would have to happen with Server specific >>> > code I guess, >>> > just as Weld now requires an SPI to obtain the >>> > current >>> > principal >>> > for injection. >>> > >>> > You could say that the Servlet container could >>> > store the >>> > request >>> > "somewhere" on a stack structure, just before >>> it >>> > invokes the >>> > ServerAuthModule, Filter, Servlet and anything >>> > else I >>> > may have >>> > forgotten, and then when control flows back to >>> > each Servlet, >>> > Filter, etc unwind that stack. >>> > >>> > At the very least the spec for now should >>> perhaps >>> > clarify this? >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > >>> > >>> > >>> > >>> > Martin >>> > >>> > Dne 8.9.2016 v 11:02 arjan tijms napsal(a): >>> > >>> > Hi, >>> > >>> > The CDI spec defines a built-in bean >>> for >>> > the type >>> > HttpServletRequest. In >>> > 3.8 it says: >>> > >>> > "A servlet container must provide the >>> > following >>> > built-in >>> > beans, all of >>> > which have qualifier @Default: >>> > >>> > a bean with bean type >>> > javax.servlet.http.HttpServletRequest, >>> > allowing >>> > injection of a reference to the >>> > HttpServletRequest" >>> > >>> > An HttpServletRequest however can be >>> wrapped >>> > multiple >>> > times and by >>> > multiple artefacts. I.e. by a >>> > ServerAuthModule, >>> > Filter and a >>> > RequestDispatcher. >>> > >>> > The question now is; which version of >>> the >>> > HttpServletRequest is supposed >>> > to be injected? >>> > >>> > * The first one in the chain? >>> > * The last one in the chain? >>> > * The current one at a given point in >>> > the chain? >>> > >>> > A little bit of experimenting seems to >>> > indicate >>> > it's now >>> > often "one of >>> > the first ones", e.g. the one that >>> > happened to be >>> > current when e.g. a >>> > ServletRequestListener that >>> initialises a >>> > specific CDI >>> > implementation is >>> > called. >>> > >>> > I think this is a little confusing, as >>> > working >>> > with an >>> > injected request >>> > can now totally ignore the request >>> > wrapping that has >>> > been done and break >>> > an application badly. >>> > >>> > Thoughts? >>> > >>> > Kind regards, >>> > Arjan Tijms >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > cdi-dev mailing list >>> > cdi-dev at lists.jboss.org >>> > >>> > >> > > >>> > >> g> >>> > >> > >> >>> > >>> > 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 >>> > >> cdi-dev at lists.jboss.org >>> > > >>> > >> > >> cdi-dev at lists.jboss.org >>> > >> >>> > https://lists.jboss.org/mailm >>> an/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/licens >>> es/LICENSE-2.0.html >>> > >>> > >> > > >>> > >> es/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 >>> > >>> > >>> >>> -- >>> 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/license >>> s/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/20160913/528c0304/attachment-0001.html From issues at jboss.org Thu Sep 15 03:38:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 15 Sep 2016 03:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-631: ------------------------------------- Fix Version/s: 2.0 (discussion) > Improve AnnotationLiteral for empty annotations > ----------------------------------------------- > > Key: CDI-631 > URL: https://issues.jboss.org/browse/CDI-631 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Mark Struberg > Fix For: 2.0 (discussion) > > > Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + + > That's horrible expensive. > In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members: > https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/annotation/EmptyAnnotationLiteral.java > The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type. > We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Thu Sep 15 04:15:04 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 15 Sep 2016 10:15:04 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: References: Message-ID: <0FFADE33-8A06-44B1-A917-C5301C6C3339@sabot-durand.net> Just a naive remark regarding Instance of annotations without members. I already used a lambda to have such an instance: BeanManager.getBeans(MyBean.class, () -> MyQualifier.class) I?m not sure there are no problem by using this short cut, but it is quite convenient. Antoine > Le 12 sept. 2016 ? 12:28, arjan tijms a ?crit : > > Hi, > > Wouldn't it be convenient as the CDI API that now requires an Annotation instance in various APIs, would also accept the class type of that Annotation? > > E.g. in BeanManager there's this method: > > Set> getBeans(Type beanType, Annotation... qualifiers) > > This not rarely requires one to create an AnnotationLiteral, which is not specifically difficult but a tad verbose. For qualifiers that have no (binding) attributes, a simple Class would be much easier to use. > > Thoughts? > > Kind regards, > Arjan Tijms > _______________________________________________ > 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 mkouba at redhat.com Thu Sep 15 04:26:11 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 15 Sep 2016 10:26:11 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: <0FFADE33-8A06-44B1-A917-C5301C6C3339@sabot-durand.net> References: <0FFADE33-8A06-44B1-A917-C5301C6C3339@sabot-durand.net> Message-ID: <5251a771-50d9-91bb-3613-cb7d1d615f6d@redhat.com> Dne 15.9.2016 v 10:15 Antoine Sabot-Durand napsal(a): > Just a naive remark regarding Instance of annotations without members. I already used a lambda to have such an instance: > > BeanManager.getBeans(MyBean.class, () -> MyQualifier.class) What is this cryptic unclear lambda thing doing actually? I know it compiles but I don't understand... > > I?m not sure there are no problem by using this short cut, but it is quite convenient. > > Antoine > > >> Le 12 sept. 2016 ? 12:28, arjan tijms a ?crit : >> >> Hi, >> >> Wouldn't it be convenient as the CDI API that now requires an Annotation instance in various APIs, would also accept the class type of that Annotation? >> >> E.g. in BeanManager there's this method: >> >> Set> getBeans(Type beanType, Annotation... qualifiers) >> >> This not rarely requires one to create an AnnotationLiteral, which is not specifically difficult but a tad verbose. For qualifiers that have no (binding) attributes, a simple Class would be much easier to use. >> >> Thoughts? >> >> Kind regards, >> Arjan Tijms >> _______________________________________________ >> 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 antoine at sabot-durand.net Thu Sep 15 04:48:32 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 15 Sep 2016 10:48:32 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: <5251a771-50d9-91bb-3613-cb7d1d615f6d@redhat.com> References: <0FFADE33-8A06-44B1-A917-C5301C6C3339@sabot-durand.net> <5251a771-50d9-91bb-3613-cb7d1d615f6d@redhat.com> Message-ID: <93FD4D7B-B286-484F-A476-1A81DEEFF10F@sabot-durand.net> > Le 15 sept. 2016 ? 10:26, Martin Kouba a ?crit : > > Dne 15.9.2016 v 10:15 Antoine Sabot-Durand napsal(a): >> Just a naive remark regarding Instance of annotations without members. I already used a lambda to have such an instance: >> >> BeanManager.getBeans(MyBean.class, () -> MyQualifier.class) > > What is this cryptic unclear lambda thing doing actually? I know it compiles but I don't understand? It compiles and works every the time I used it. From my understanding it?s a short cut for BeanManager.getBeans(MyBean.class, new Annotation() { @Override public Class annotationType() { return MyQualifier.class; } }) Which by the way also works. From your answer I guess it?s a bad solution ;), but I?d be happy to know why and what is the side effect makes it work. Thanks, Antoine > >> >> I?m not sure there are no problem by using this short cut, but it is quite convenient. >> >> Antoine >> >> >>> Le 12 sept. 2016 ? 12:28, arjan tijms a ?crit : >>> >>> Hi, >>> >>> Wouldn't it be convenient as the CDI API that now requires an Annotation instance in various APIs, would also accept the class type of that Annotation? >>> >>> E.g. in BeanManager there's this method: >>> >>> Set> getBeans(Type beanType, Annotation... qualifiers) >>> >>> This not rarely requires one to create an AnnotationLiteral, which is not specifically difficult but a tad verbose. For qualifiers that have no (binding) attributes, a simple Class would be much easier to use. >>> >>> Thoughts? >>> >>> Kind regards, >>> Arjan Tijms >>> _______________________________________________ >>> 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 mkouba at redhat.com Thu Sep 15 05:03:36 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 15 Sep 2016 11:03:36 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: <93FD4D7B-B286-484F-A476-1A81DEEFF10F@sabot-durand.net> References: <0FFADE33-8A06-44B1-A917-C5301C6C3339@sabot-durand.net> <5251a771-50d9-91bb-3613-cb7d1d615f6d@redhat.com> <93FD4D7B-B286-484F-A476-1A81DEEFF10F@sabot-durand.net> Message-ID: <4cb4aa28-e5ae-6229-aa85-a8bece27bfdd@redhat.com> Dne 15.9.2016 v 10:48 Antoine Sabot-Durand napsal(a): > >> Le 15 sept. 2016 ? 10:26, Martin Kouba a ?crit : >> >> Dne 15.9.2016 v 10:15 Antoine Sabot-Durand napsal(a): >>> Just a naive remark regarding Instance of annotations without members. I already used a lambda to have such an instance: >>> >>> BeanManager.getBeans(MyBean.class, () -> MyQualifier.class) >> >> What is this cryptic unclear lambda thing doing actually? I know it compiles but I don't understand? > > It compiles and works every the time I used it. From my understanding it?s a short cut for > > BeanManager.getBeans(MyBean.class, new Annotation() { > @Override > public Class annotationType() { > return MyQualifier.class; > } > }) > > Which by the way also works. From your answer I guess it?s a bad solution ;), but I?d be happy to know why and what is the side effect makes it work. I don't say it's a bad solution, but it's not obvious and I consider similar things a bad practice, especially if we don't understand why it works ;-) > > Thanks, > > Antoine > >> >>> >>> I?m not sure there are no problem by using this short cut, but it is quite convenient. >>> >>> Antoine >>> >>> >>>> Le 12 sept. 2016 ? 12:28, arjan tijms a ?crit : >>>> >>>> Hi, >>>> >>>> Wouldn't it be convenient as the CDI API that now requires an Annotation instance in various APIs, would also accept the class type of that Annotation? >>>> >>>> E.g. in BeanManager there's this method: >>>> >>>> Set> getBeans(Type beanType, Annotation... qualifiers) >>>> >>>> This not rarely requires one to create an AnnotationLiteral, which is not specifically difficult but a tad verbose. For qualifiers that have no (binding) attributes, a simple Class would be much easier to use. >>>> >>>> Thoughts? >>>> >>>> Kind regards, >>>> Arjan Tijms >>>> _______________________________________________ >>>> 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. >>> > -- Martin Kouba Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Thu Sep 15 05:21:41 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 15 Sep 2016 11:21:41 +0200 Subject: [cdi-dev] Accepting class type for simple (qualifier) annotations in APIs? In-Reply-To: <4cb4aa28-e5ae-6229-aa85-a8bece27bfdd@redhat.com> References: <0FFADE33-8A06-44B1-A917-C5301C6C3339@sabot-durand.net> <5251a771-50d9-91bb-3613-cb7d1d615f6d@redhat.com> <93FD4D7B-B286-484F-A476-1A81DEEFF10F@sabot-durand.net> <4cb4aa28-e5ae-6229-aa85-a8bece27bfdd@redhat.com> Message-ID: After some test I can answer myself. It?s bad because equals() is broken (2 annotations created with this code won?t be equals). And it works probably because all the equals call done in Weld are made from the inner Annotation not from user instance? Also Annotation is not a functional interface. Antoine > Le 15 sept. 2016 ? 11:03, Martin Kouba a ?crit : > > Dne 15.9.2016 v 10:48 Antoine Sabot-Durand napsal(a): >> >>> Le 15 sept. 2016 ? 10:26, Martin Kouba a ?crit : >>> >>> Dne 15.9.2016 v 10:15 Antoine Sabot-Durand napsal(a): >>>> Just a naive remark regarding Instance of annotations without members. I already used a lambda to have such an instance: >>>> >>>> BeanManager.getBeans(MyBean.class, () -> MyQualifier.class) >>> >>> What is this cryptic unclear lambda thing doing actually? I know it compiles but I don't understand? >> >> It compiles and works every the time I used it. From my understanding it?s a short cut for >> >> BeanManager.getBeans(MyBean.class, new Annotation() { >> @Override >> public Class annotationType() { >> return MyQualifier.class; >> } >> }) >> >> Which by the way also works. From your answer I guess it?s a bad solution ;), but I?d be happy to know why and what is the side effect makes it work. > > I don't say it's a bad solution, but it's not obvious and I consider similar things a bad practice, especially if we don't understand why it works ;-) > >> >> Thanks, >> >> Antoine >> >>> >>>> >>>> I?m not sure there are no problem by using this short cut, but it is quite convenient. >>>> >>>> Antoine >>>> >>>> >>>>> Le 12 sept. 2016 ? 12:28, arjan tijms a ?crit : >>>>> >>>>> Hi, >>>>> >>>>> Wouldn't it be convenient as the CDI API that now requires an Annotation instance in various APIs, would also accept the class type of that Annotation? >>>>> >>>>> E.g. in BeanManager there's this method: >>>>> >>>>> Set> getBeans(Type beanType, Annotation... qualifiers) >>>>> >>>>> This not rarely requires one to create an AnnotationLiteral, which is not specifically difficult but a tad verbose. For qualifiers that have no (binding) attributes, a simple Class would be much easier to use. >>>>> >>>>> Thoughts? >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> _______________________________________________ >>>>> 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. >>>> >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160915/e27b555b/attachment-0001.html From issues at jboss.org Thu Sep 15 06:44:00 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 15 Sep 2016 06:44:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-632) Does implicit bean archive should exist in Java SE In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-632: ---------------------------------------- Summary: Does implicit bean archive should exist in Java SE Key: CDI-632 URL: https://issues.jboss.org/browse/CDI-632 Project: CDI Specification Issues Issue Type: Clarification Components: Java SE Integration Affects Versions: 2.0-EDR2 Reporter: Antoine Sabot-Durand Current implementation of CDI 2.0 EDR2 doesn't support implicit bean archive (see WELD-2233) where the spec says it is available in core and thus Java SE. We need to clarify the spec or correct the impl... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 07:00:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 15 Sep 2016 07:00:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-632: ------------------------------------- Summary: Possible conflict for Implicit bean archive definition between core and SE (was: Does implicit bean archive should exist in Java SE) > Possible conflict for Implicit bean archive definition between core and SE > -------------------------------------------------------------------------- > > Key: CDI-632 > URL: https://issues.jboss.org/browse/CDI-632 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > > Current implementation of CDI 2.0 EDR2 doesn't support implicit bean archive (see WELD-2233) where the spec says it is available in core and thus Java SE. > We need to clarify the spec or correct the impl... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 07:05:02 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 15 Sep 2016 07:05:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-632: ------------------------------------- Description: Section 12.1 (which should be satisfied in SE an EE) states: bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations. And section 15.1 reads: {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that : An archive which doesn?t contain a beans.xml file can?t be discovered as an implicit bean archive unless: * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote} Perhaps this deserve a bit of clarification. was: Current implementation of CDI 2.0 EDR2 doesn't support implicit bean archive (see WELD-2233) where the spec says it is available in core and thus Java SE. We need to clarify the spec or correct the impl... > Possible conflict for Implicit bean archive definition between core and SE > -------------------------------------------------------------------------- > > Key: CDI-632 > URL: https://issues.jboss.org/browse/CDI-632 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > > Section 12.1 (which should be satisfied in SE an EE) states: > bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations. > And section 15.1 reads: > {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that : > An archive which doesn?t contain a beans.xml file can?t be discovered as an implicit bean archive unless: > * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or > * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote} > Perhaps this deserve a bit of clarification. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 07:05:05 2016 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 15 Sep 2016 07:05:05 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-632: ------------------------------------- Priority: Minor (was: Major) > Possible conflict for Implicit bean archive definition between core and SE > -------------------------------------------------------------------------- > > Key: CDI-632 > URL: https://issues.jboss.org/browse/CDI-632 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > Priority: Minor > > Section 12.1 (which should be satisfied in SE an EE) states: > bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations. > And section 15.1 reads: > {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that : > An archive which doesn?t contain a beans.xml file can?t be discovered as an implicit bean archive unless: > * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or > * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote} > Perhaps this deserve a bit of clarification. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 16 12:58:00 2016 From: issues at jboss.org (Stephan Knitelius (JIRA)) Date: Fri, 16 Sep 2016 12:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294677#comment-13294677 ] Stephan Knitelius commented on CDI-632: --------------------------------------- I am not a fan of implicit bean archives, but wouldn't it be better if SE worked the same? > Possible conflict for Implicit bean archive definition between core and SE > -------------------------------------------------------------------------- > > Key: CDI-632 > URL: https://issues.jboss.org/browse/CDI-632 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Antoine Sabot-Durand > Priority: Minor > > Section 12.1 (which should be satisfied in SE an EE) states: > bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations. > And section 15.1 reads: > {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that : > An archive which doesn?t contain a beans.xml file can?t be discovered as an implicit bean archive unless: > * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or > * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote} > Perhaps this deserve a bit of clarification. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 07:10:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 20 Sep 2016 07:10:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: Martin Kouba created CDI-633: -------------------------------- Summary: Intoroduce BeanManager.event() Key: CDI-633 URL: https://issues.jboss.org/browse/CDI-633 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 07:11:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 20 Sep 2016 07:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-633: ----------------------------- Fix Version/s: 2.0 (discussion) > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 07:58:00 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Tue, 20 Sep 2016 07:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295614#comment-13295614 ] Sven Linstaedt commented on CDI-633: ------------------------------------ For the current more extension-related BeanManager API ({{BeanManager#fire}}), which is not capable of handling event type narrowing by a specific {{java.lang.reflect.Type}}, a similar solution would be nice too. > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 08:19:00 2016 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 20 Sep 2016 08:19:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295640#comment-13295640 ] Matej Novotny commented on CDI-633: ----------------------------------- [~tzwoenn] what you describe is what this proposal solves. {{BeanManager#fire}} cannot handle narrowing and does not allow to fire events asynchronously - and we cannot change that because of the famous backward compatibility. Having {{BeanManager#event}} as a new method on BM will grant you acces to {{Event}} where you can narrow the type with {{select(...)}} and then {{fire()}} or {{fireAsync}}. > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 08:32:01 2016 From: issues at jboss.org (Sven Linstaedt (JIRA)) Date: Tue, 20 Sep 2016 08:32:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-633) Intoroduce BeanManager.event() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295652#comment-13295652 ] Sven Linstaedt commented on CDI-633: ------------------------------------ [~manovotn] Not completely: {{javax.enterprise.event.Event}} is meant for application driven event triggering. In order to narrow down the event type, you can either specify a {{java.lang.Class}} or a for generics a {{javax.enterprise.util.TypeLiteral}}. As an extension developer, {{Event}} is not sufficient as you can neither # resolve {{Event}} before{{AfterDeploymentValidation}} nor # narrow down the event type by an extension-resolved {{java.lang.reflect.Type}}, which can not be hardcoded using {{TypeLiteral}} as the static type is not known to the extension and TypeLiteral was not meant for being created out of some unknown {{Type}}. So there is still a need for extending the existing method {{BeanManager#fire}} and of course keeping it backwards compatible as mentioned in CDI-493. > Intoroduce BeanManager.event() > ------------------------------ > > Key: CDI-633 > URL: https://issues.jboss.org/browse/CDI-633 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types > * the method should return {{javax.enterprise.event.Event}} with no qualifiers -- This message was sent by Atlassian JIRA (v6.4.11#64026) From struberg at yahoo.de Tue Sep 20 09:07:57 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 20 Sep 2016 13:07:57 +0000 (UTC) Subject: [cdi-dev] proxy unwrapping References: <2022097502.1533196.1474376877946.ref@mail.yahoo.com> Message-ID: <2022097502.1533196.1474376877946@mail.yahoo.com> Hi! I found another one who did similar things than I did: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160920/66200653/attachment.html From struberg at yahoo.de Tue Sep 20 09:09:03 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 20 Sep 2016 13:09:03 +0000 (UTC) Subject: [cdi-dev] proxy unwrapping In-Reply-To: <2022097502.1533196.1474376877946@mail.yahoo.com> References: <2022097502.1533196.1474376877946.ref@mail.yahoo.com> <2022097502.1533196.1474376877946@mail.yahoo.com> Message-ID: <291478834.1507049.1474376943827@mail.yahoo.com> premature enter due to NoCoffeeException ... Missed the link ;) https://dev.vaadin.com/ticket/14639 LieGrue,strub On Tuesday, 20 September 2016, 15:07, Mark Struberg wrote: Hi! I found another one who did similar things than I did: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160920/86ad7c4b/attachment.html From john.ament at spartasystems.com Tue Sep 20 13:07:22 2016 From: john.ament at spartasystems.com (John Ament) Date: Tue, 20 Sep 2016 17:07:22 +0000 Subject: [cdi-dev] Proposed times for video chat on context management APIs Message-ID: All, In talking with Antoine this morning, the proposal is going to be to keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a google hangout. We need at least myself, Martin and Mark on the video (Antoine would like to be there as well [?] ). So does that time work for everyone? If not, do any other times on Tuesday work? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160920/12c45c06/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: OutlookEmoji-?.png Type: image/png Size: 390 bytes Desc: =?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIkucG5n?= Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160920/12c45c06/attachment.png From struberg at yahoo.de Tue Sep 20 15:01:01 2016 From: struberg at yahoo.de (Mark Struberg) Date: Tue, 20 Sep 2016 19:01:01 +0000 (UTC) Subject: [cdi-dev] Proposed times for video chat on context management APIs In-Reply-To: References: Message-ID: <663155101.1760792.1474398062028@mail.yahoo.com> Hi John! I can Mon, Thue, Wed in the evening (CEST) LieGrue, strub On Tuesday, 20 September 2016, 19:08, John Ament wrote: > > > >All, > > >In talking with Antoine this morning, the proposal is going to be to keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a google hangout. We need at least myself, Martin and Mark on the video (Antoine would like to be there as well ). So does that time work for everyone? > > >If not, do any other times on Tuesday work? > > >John > > >________________________________ > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. >_______________________________________________ >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 mkouba at redhat.com Wed Sep 21 04:41:05 2016 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 21 Sep 2016 10:41:05 +0200 Subject: [cdi-dev] Proposed times for video chat on context management APIs In-Reply-To: References: Message-ID: <3762d850-0ee1-3976-0db5-1b4fe9c85dbb@redhat.com> Tuesday's mtg time (18.00 CEST) should work for me. Thanks, Martin Dne 20.9.2016 v 19:07 John Ament napsal(a): > All, > > > In talking with Antoine this morning, the proposal is going to be to > keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a > google hangout. We need at least myself, Martin and Mark on the video > (Antoine would like to be there as well ?). So does that time work for > everyone? > > > If not, do any other times on Tuesday work? > > > John > > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > 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 john.ament at spartasystems.com Wed Sep 21 09:45:06 2016 From: john.ament at spartasystems.com (John Ament) Date: Wed, 21 Sep 2016 13:45:06 +0000 Subject: [cdi-dev] Proposed times for video chat on context management APIs In-Reply-To: <3762d850-0ee1-3976-0db5-1b4fe9c85dbb@redhat.com> References: , <3762d850-0ee1-3976-0db5-1b4fe9c85dbb@redhat.com> Message-ID: Ok, thanks Mark - does Tuesday's meeting work for you as well? ________________________________ From: Martin Kouba Sent: Wednesday, September 21, 2016 4:41 AM To: John Ament; cdi-dev Subject: Re: [cdi-dev] Proposed times for video chat on context management APIs Tuesday's mtg time (18.00 CEST) should work for me. Thanks, Martin Dne 20.9.2016 v 19:07 John Ament napsal(a): > All, > > > In talking with Antoine this morning, the proposal is going to be to > keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a > google hangout. We need at least myself, Martin and Mark on the video > (Antoine would like to be there as well ??). So does that time work for > everyone? > > > If not, do any other times on Tuesday work? > > > John > > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev cdi-dev Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > > 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. > ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160921/0614cd1d/attachment-0001.html From struberg at yahoo.de Fri Sep 23 03:45:57 2016 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 23 Sep 2016 07:45:57 +0000 (UTC) Subject: [cdi-dev] Proposed times for video chat on context management APIs In-Reply-To: References: <3762d850-0ee1-3976-0db5-1b4fe9c85dbb@redhat.com> Message-ID: <1568606075.172919.1474616757886@mail.yahoo.com> yes, works fine. LieGrue, strub On Wednesday, 21 September 2016, 15:45, John Ament wrote: > > >Ok, thanks > > >Mark - does Tuesday's meeting work for you as well? > > > >________________________________ > >From: Martin Kouba >Sent: Wednesday, September 21, 2016 4:41 AM >To: John Ament; cdi-dev >Subject: Re: [cdi-dev] Proposed times for video chat on context management APIs > >Tuesday's mtg time (18.00 CEST) should work for me. > >Thanks, >Martin > >Dne 20.9.2016 v 19:07 John Ament napsal(a): >> All, >> >> >> In talking with Antoine this morning, the proposal is going to be to >> keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a >> google hangout. We need at least myself, Martin and Mark on the video >> (Antoine would like to be there as well ). So does that time work for >> everyone? >> >> >> If not, do any other times on Tuesday work? >> >> >> John >> >> >> ------------------------------------------------------------------------ >> NOTICE: This e-mail message and any attachments may contain >> confidential, proprietary, and/or privileged information which should be >> treated accordingly. If you are not the intended recipient, please >> notify the sender immediately by return e-mail, delete this message, and >> destroy all physical and electronic copies. Thank you. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >cdi-dev Info Page - JBoss Developer >lists.jboss.org >List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. > >> >> 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. > >> > > >________________________________ > NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. > >_______________________________________________ >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 Sun Sep 25 03:51:00 2016 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Sun, 25 Sep 2016 03:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298149#comment-13298149 ] Mark Struberg commented on CDI-420: ----------------------------------- 2 weeks passed and no better idea. So I assume that we stick with: {code} {code} In which case I would love to add this to DeltaSpike and do some advanced testing with it. I will add this to OWB and I assume Martin will also enhance Weld to support it. In which case we have already get very good feedback from real world projects. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Sep 25 17:47:00 2016 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Sun, 25 Sep 2016 17:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298154#comment-13298154 ] Emily Jiang commented on CDI-420: --------------------------------- +1 > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Sep 25 18:22:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Sun, 25 Sep 2016 18:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298156#comment-13298156 ] John Ament commented on CDI-420: -------------------------------- Don't forget to raise a PR with the spec changes. That will be when the real discussion happens. > add a bean-discovery-mode 'scoped' > ---------------------------------- > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Mon Sep 26 10:54:43 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 26 Sep 2016 14:54:43 +0000 Subject: [cdi-dev] Proposed times for video chat on context management APIs In-Reply-To: References: <3762d850-0ee1-3976-0db5-1b4fe9c85dbb@redhat.com> Message-ID: Waiting for your answer here Mark. I'll send an invitation for Hangout link after your green light ;) Antoine Le mer. 21 sept. 2016 ? 15:45, John Ament a ?crit : > Ok, thanks > > > Mark - does Tuesday's meeting work for you as well? > > > ------------------------------ > *From:* Martin Kouba > *Sent:* Wednesday, September 21, 2016 4:41 AM > *To:* John Ament; cdi-dev > *Subject:* Re: [cdi-dev] Proposed times for video chat on context > management APIs > > Tuesday's mtg time (18.00 CEST) should work for me. > > Thanks, > Martin > > Dne 20.9.2016 v 19:07 John Ament napsal(a): > > All, > > > > > > In talking with Antoine this morning, the proposal is going to be to > > keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a > > google hangout. We need at least myself, Martin and Mark on the video > > (Antoine would like to be there as well ?). So does that time work for > > everyone? > > > > > > If not, do any other times on Tuesday work? > > > > > > John > > > > > > ------------------------------------------------------------------------ > > NOTICE: This e-mail message and any attachments may contain > > confidential, proprietary, and/or privileged information which should be > > treated accordingly. If you are not the intended recipient, please > > notify the sender immediately by return e-mail, delete this message, and > > destroy all physical and electronic copies. Thank you. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > cdi-dev Info Page - JBoss Developer > > lists.jboss.org > List to discuss the development of CDI (the specification) To see the > collection of prior postings to the list, visit the cdi-dev Archives. > > > > > > 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. > > > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > _______________________________________________ > 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/20160926/e8ca6762/attachment-0001.html From antoine at sabot-durand.net Mon Sep 26 11:11:52 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 26 Sep 2016 15:11:52 +0000 Subject: [cdi-dev] Proposed times for video chat on context management APIs In-Reply-To: References: <3762d850-0ee1-3976-0db5-1b4fe9c85dbb@redhat.com> Message-ID: Sorry Mark, missed your answer in my mailbox. I send an invitation right away. Antoine Le lun. 26 sept. 2016 ? 16:54, Antoine Sabot-Durand < antoine at sabot-durand.net> a ?crit : > Waiting for your answer here Mark. I'll send an invitation for Hangout > link after your green light ;) > > Antoine > > > > Le mer. 21 sept. 2016 ? 15:45, John Ament > a ?crit : > >> Ok, thanks >> >> >> Mark - does Tuesday's meeting work for you as well? >> >> >> ------------------------------ >> *From:* Martin Kouba >> *Sent:* Wednesday, September 21, 2016 4:41 AM >> *To:* John Ament; cdi-dev >> *Subject:* Re: [cdi-dev] Proposed times for video chat on context >> management APIs >> >> Tuesday's mtg time (18.00 CEST) should work for me. >> >> Thanks, >> Martin >> >> Dne 20.9.2016 v 19:07 John Ament napsal(a): >> > All, >> > >> > >> > In talking with Antoine this morning, the proposal is going to be to >> > keep next Tuesday's meeting. Instead of hosting on IRC, we'll do a >> > google hangout. We need at least myself, Martin and Mark on the video >> > (Antoine would like to be there as well ?). So does that time work for >> > everyone? >> > >> > >> > If not, do any other times on Tuesday work? >> > >> > >> > John >> > >> > >> > ------------------------------------------------------------------------ >> > NOTICE: This e-mail message and any attachments may contain >> > confidential, proprietary, and/or privileged information which should be >> > treated accordingly. If you are not the intended recipient, please >> > notify the sender immediately by return e-mail, delete this message, and >> > destroy all physical and electronic copies. Thank you. >> > >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> cdi-dev Info Page - JBoss Developer >> >> lists.jboss.org >> List to discuss the development of CDI (the specification) To see the >> collection of prior postings to the list, visit the cdi-dev Archives. >> >> >> > >> > 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. >> > >> ------------------------------ >> NOTICE: This e-mail message and any attachments may contain confidential, >> proprietary, and/or privileged information which should be treated >> accordingly. If you are not the intended recipient, please notify the >> sender immediately by return e-mail, delete this message, and destroy all >> physical and electronic copies. Thank you. >> _______________________________________________ >> 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/20160926/336741d8/attachment.html From antoine at sabot-durand.net Mon Sep 26 11:16:18 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 26 Sep 2016 15:16:18 +0000 Subject: [cdi-dev] Invitation: CDI Ctx management Hangout @ Tue Sep 27, 2016 18:00 - 19:00 (CEST) (ASD Perso) Message-ID: <001a114b6ab61c5df3053d6a9cbe@google.com> You have been invited to the following event. Title: CDI Ctx management Hangout Discussing about CDI-30 When: Tue Sep 27, 2016 18:00 ? 19:00 Paris Where: Hangout Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine Calendar: ASD Perso Who: * Antoine Sabot-Durand - organizer * Mark Struberg * mkouba at redhat.com * John D. Ament * cdi-dev at lists.jboss.org - optional Your attendance is optional. Event details: https://www.google.com/calendar/event?action=VIEW&eid=Xzg5MmphZDluNzRxNGNiYTU4OHI0OGI5azZjb2s0YjlwNmwzMzJiYTM2b29qYWMyMThnb2o0ZTlsOGcgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZjY4OTQwNzNiODVjZWQ3MjIxNjliMDUxZDBiOTQzOGEzOWZiNmRjOA&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/20160926/2a94a6ce/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1842 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160926/2a94a6ce/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1881 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160926/2a94a6ce/attachment-0003.bin From issues at jboss.org Mon Sep 26 12:55:01 2016 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 26 Sep 2016 12:55:01 -0400 (EDT) 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=13298597#comment-13298597 ] Guillermo Gonz?lez de Ag?ero commented on CDI-370: -------------------------------------------------- Just wondering, could CDI-30 be used to solve cases like this? > 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 Tue Sep 27 03:48:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 27 Sep 2016 03:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE In-Reply-To: References: Message-ID: Martin Kouba created CDI-634: -------------------------------- Summary: Clarify contextual reference validity to a bean with a normal scope in Java SE Key: CDI-634 URL: https://issues.jboss.org/browse/CDI-634 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: # start CDI container # get a reference # stop CDI container # start CDI container again and try to use the stored reference. I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 07:20:01 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 27 Sep 2016 07:20:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298924#comment-13298924 ] John Ament commented on CDI-634: -------------------------------- Not sure why you need spec clarification on this. The complaint on WELD-2190 is that "ContextNotActive" is not the right exception to throw. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 07:34:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 27 Sep 2016 07:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298937#comment-13298937 ] Martin Kouba commented on CDI-634: ---------------------------------- [~meetoblivion] Because I think it's undefined. And by the way it seems you've also agreed this would deserve some clarification - https://issues.jboss.org/browse/WELD-2190?focusedCommentId=13263160&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13263160. The exception is just an implementation detail. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 07:36:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 27 Sep 2016 07:36:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-634) Clarify contextual reference validity to a bean with a normal scope in Java SE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298940#comment-13298940 ] John Ament commented on CDI-634: -------------------------------- Well, my response was "may" since OWB does something completely different. > Clarify contextual reference validity to a bean with a normal scope in Java SE > ------------------------------------------------------------------------------ > > Key: CDI-634 > URL: https://issues.jboss.org/browse/CDI-634 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > In Java SE, a user might be tempted to share a contextual reference for a normal scoped bean (client proxy) between multiple "deployments" of a single application, e.g.: > # start CDI container > # get a reference > # stop CDI container > # start CDI container again and try to use the stored reference. > I believe such a reference should not be valid after an application stopped (contexts are destroyed, etc.). Right now, it seems to be undefined. > See also WELD-2190. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 07:41:00 2016 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 27 Sep 2016 07:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298942#comment-13298942 ] John Ament commented on CDI-625: -------------------------------- I'm -1 to the changes in the PR. I don't see how after destroyed is useful, due to beans being destroyed. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 07:52:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 27 Sep 2016 07:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13298949#comment-13298949 ] Martin Kouba commented on CDI-625: ---------------------------------- {{@AfterDestroyed}} is the new {{@Destroyed}} - just to have consistent names. And if you ask for purpose - it's just backward compatibility. We cannot change the behavior of {{@Destroyed}} and we cannot remove the annotation either. [~antoinesabot-durand] Please correct me if I'm wrong. > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{@Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 02:54:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 29 Sep 2016 02:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300098#comment-13300098 ] Martin Kouba commented on CDI-452: ---------------------------------- I think there are basically two questions here: # Should the request context be active during a Concurrency Utilities task execution # Should the request be also propagated (as defined in [6.3. Normal scopes and pseudo-scopes|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#normal_scope]) I'm +1 for context activation but -1 for context propagation - the same applies to EJB asynchronous method invocations, timers and JMS message listeners (see also [6.7. Context management for built-in scopes|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#builtin_contexts]). > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts, Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 03:16:00 2016 From: issues at jboss.org (Ochieng Marembo (JIRA)) Date: Thu, 29 Sep 2016 03:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300104#comment-13300104 ] Ochieng Marembo commented on CDI-452: ------------------------------------- In my opinion, i think the case for context-propagation is still of noteworthy here. Consider the following scenarios: 1. User is logged in, and hence the user logged in state is on session 2. We need to process several reports pertaining to the currently logged in user, of which, we have designed our API to simply allow us to inject the currently logged in user, as thus {code:java} @Inject private User loggedInUser; {code} 3. Assume to generate this report, we need to communicate with 3 or so external services which requires currently logged in user, hence, the services may look like this: {code:java} @ApplicationScoped public class UserOrderService { @Inject private Instance loggedInUser; List
getOrderArticles() { //External service call } } @ApplicationScoped public class UserCartService { @Inject private Instance loggedInUser; List
getArticlesInCart() { //External service call } } @ApplicationScoped public class UserWishlistService { @Inject private Instance loggedInUser; List
getArticlesInWishlist() { //External service call } } {code} 4. We want to invoke this services, asynchronously. Of course we can simply pass the user context as parameters of the methods, but then, we will need to pass it on every possible method, just in order that it ends up where it is required. Other methods will unnecessarily be accepting a parameter, just in order that someone down the trail may need it. 5. It is up to the developer, to ensure that the execution of the async calls, all complete if their results are needed for the response. 6. We can also design the asynchronous task to be long-running, so that we fire and forget, and the response can be sent to client if and when the required async calls are complete, ignoring all async calls marked as long-running (or fire-and-forget) 7. The CDI current inability to propagate request/session contexts to async calls, (and equivalently the ejb @Asynchronous) makes it practically impossible to perform several tasks within a single request that requires current request context, making CDI services hugely slow, and not using the processing power of CPU, unless one resorts to complicated parameter based context passing, which is really inconveniencing. > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts, Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 03:19:00 2016 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 29 Sep 2016 03:19:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300106#comment-13300106 ] Romain Manni-Bucau commented on CDI-452: ---------------------------------------- +1, also note that not propagating the main context makes it pretty useless. Takes a simple and very common use case where you have a security filter pushing data in a request scoped bean (display name, login etc...) and a @Suspended jaxrs endpoint then no way to get the filter data. This is not only about EE concurrency but a way to let user propagate properly a context - then thread safety etc is up to him. So we need a cdiWhatever = enterContext(scope); ....; exitContext(cdiWhatever); There are really no technical blocker for that and would make context far more powerful in nowadays world using more and more such a things. > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts, Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 04:21:00 2016 From: issues at jboss.org (arjan tijms (JIRA)) Date: Thu, 29 Sep 2016 04:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300128#comment-13300128 ] arjan tijms commented on CDI-452: --------------------------------- {quote}User is logged in, and hence the user logged in state is on session{quote} In Java EE the logged-in state is Primarily set on the request. The session may hold details that make it easier or trivial to re-authenticate each request. {quote}We need to process several reports pertaining to the currently logged in user, of which, we have designed our API to simply allow us to inject the currently logged in user, as thus{quote} Java EE already has the (somewhat opaque) concept of a {{security context}} being propagated, which is independent from the request, session or any other scope. This mostly comes into play when a remote EJB bean is being called, but technically also when local beans are called. JCA also has a definition for this (inflow security). What this basically means is that when calling an asynchronous method or scheduling work on a concurrency utils thread pool, the container can make the {{Caller Principal}} and its roles available (propagates those). If you then have say a producer for which CDI checks if your application specific {{User}} instance is already available in request scope and if not instantiates one by calling your producer method which then uses the name of the current principal, your application can pretty much function as you indicated above without the necessity to propagate the request scope. > Specify that web scoped (request, session, application) beans are injectable in async servlets > ---------------------------------------------------------------------------------------------- > > Key: CDI-452 > URL: https://issues.jboss.org/browse/CDI-452 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts, Java EE integration > Affects Versions: 1.0 > Reporter: Ed Burns > Assignee: John Ament > Fix For: 2.0 (discussion) > > > Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >. > {code} > @WebServlet(urlPatterns="/test2", asyncSupported=true) > public class TestAsyncMESServlet extends HttpServlet { > @Resource > private ManagedExecutorService managedExecutorService; > @Inject > MyRunnableImpl myRunnableImpl; > @Override > protected void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException { > final AsyncContext asyncContext = req.startAsync(); > final PrintWriter writer = res.getWriter(); > managedExecutorService.submit(myRunnableImpl); > } > public static class MyRunnableImpl implements Runnable { > @Inject > Bean bean; // Bean is @RequestScoped > @Override > public void run() { > writer.println("Done"); > asyncContext.complete(); > } > } > } > {code} > According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread. To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From antoine at sabot-durand.net Thu Sep 29 05:16:27 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 29 Sep 2016 09:16:27 +0000 Subject: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting Message-ID: Hi all, Just to sum up what was said during our Tuesday Hangout meeting. For those who were present feel free to correct or amend this. Controlling Request Context is something rather easy (because it's linked to one thread) while Session Context is far less obvious (used across multiple threads) so providing a generic solution to deal with their control seems quite complicated. That's why we decided to start addressing the Request Context control first and if we fell happy with that, continue the work on the Session Context. Public API to control the request context could be design in 2 different ways: 1) provide an interceptor to activate request context during the intercepted method invocation 2) provide a programmatic API accessible thru a bean (like the Conversation bean) First solution is probably the easiest way for end user (to avoid not ended context), but if we go for controlling Session Scope we won't be able to provide a simple interceptor for it and will design something like solution 2 for it. So the question is should we go for 1 or 2 or both (with a risk of confusion) ? Thanks for your feedback Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160929/9911d0a6/attachment.html From mkouba at redhat.com Thu Sep 29 05:46:55 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 29 Sep 2016 11:46:55 +0200 Subject: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting In-Reply-To: References: Message-ID: <8f7c5361-9966-b453-33d0-4a12d0b4cf1e@redhat.com> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a): > Hi all, > > Just to sum up what was said during our Tuesday Hangout meeting. For > those who were present feel free to correct or amend this. > > Controlling Request Context is something rather easy (because it's > linked to one thread) while Session Context is far less obvious (used > across multiple threads) so providing a generic solution to deal with > their control seems quite complicated. > That's why we decided to start addressing the Request Context control > first and if we fell happy with that, continue the work on the Session > Context. > > Public API to control the request context could be design in 2 different > ways: > 1) provide an interceptor to activate request context during the > intercepted method invocation This approach is also not always usable in some integration use cases where the request cannot be simply "wrapped in a single method call". For instance, in Quartz scheduler you can register a job listener with methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() - here the approach 2) would make sense. On the other hand, you could implement a JobFactory so that Job instances are beans (or at least instances obtained and injected from an InjectionTarget) and simply associate interceptor binding for its execute() method. > 2) provide a programmatic API accessible thru a bean (like the > Conversation bean) > > First solution is probably the easiest way for end user (to avoid not > ended context), but if we go for controlling Session Scope we won't be > able to provide a simple interceptor for it and will design something > like solution 2 for it. > > So the question is should we go for 1 or 2 or both (with a risk of > confusion) ? I think that both ways are legal and make sense. > > Thanks for your feedback > > 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. > From antoine at sabot-durand.net Thu Sep 29 05:57:39 2016 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 29 Sep 2016 09:57:39 +0000 Subject: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting In-Reply-To: <8f7c5361-9966-b453-33d0-4a12d0b4cf1e@redhat.com> References: <8f7c5361-9966-b453-33d0-4a12d0b4cf1e@redhat.com> Message-ID: That's also my choice: We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature. A well written JavaDoc should prevent confusion between both approach. Antoine On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba wrote: > > Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a): > > Hi all, > > > > Just to sum up what was said during our Tuesday Hangout meeting. For > > those who were present feel free to correct or amend this. > > > > Controlling Request Context is something rather easy (because it's > > linked to one thread) while Session Context is far less obvious (used > > across multiple threads) so providing a generic solution to deal with > > their control seems quite complicated. > > That's why we decided to start addressing the Request Context control > > first and if we fell happy with that, continue the work on the Session > > Context. > > > > Public API to control the request context could be design in 2 different > > ways: > > 1) provide an interceptor to activate request context during the > > intercepted method invocation > > This approach is also not always usable in some integration use cases > where the request cannot be simply "wrapped in a single method call". > > For instance, in Quartz scheduler you can register a job listener with > methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() - > here the approach 2) would make sense. On the other hand, you could > implement a JobFactory so that Job instances are beans (or at least > instances obtained and injected from an InjectionTarget) and simply > associate interceptor binding for its execute() method. > > > 2) provide a programmatic API accessible thru a bean (like the > > Conversation bean) > > > > First solution is probably the easiest way for end user (to avoid not > > ended context), but if we go for controlling Session Scope we won't be > > able to provide a simple interceptor for it and will design something > > like solution 2 for it. > > > > So the question is should we go for 1 or 2 or both (with a risk of > > confusion) ? > > I think that both ways are legal and make sense. > > > > > Thanks for your feedback > > > > 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160929/9f2d0e3b/attachment.html From struberg at yahoo.de Thu Sep 29 06:59:10 2016 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 29 Sep 2016 10:59:10 +0000 (UTC) Subject: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting In-Reply-To: References: <8f7c5361-9966-b453-33d0-4a12d0b4cf1e@redhat.com> Message-ID: <25208516.2526679.1475146750841@mail.yahoo.com> Martins argument with Quartz is a good one. Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches? So my vote is for the programmatic approach. Oh and while we are at it: If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code. Of course it is possible by code like try { beanManager.getContext(RequestScoped.class); // request context is active } catch (ContextNotActiveException cnae) { // request context is not active // start it etc. } But that seems a bit heavyweight, isn't? LieGrue, strub On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand wrote: > > >That's also my choice: >We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature. > > >A well written JavaDoc should prevent confusion between both approach. > > >Antoine > >On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba wrote: > > >>Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a): >>> Hi all, >>> >>> Just to sum up what was said during our Tuesday Hangout meeting. For >>> those who were present feel free to correct or amend this. >>> >>> Controlling Request Context is something rather easy (because it's >>> linked to one thread) while Session Context is far less obvious (used >>> across multiple threads) so providing a generic solution to deal with >>> their control seems quite complicated. >>> That's why we decided to start addressing the Request Context control >>> first and if we fell happy with that, continue the work on the Session >>> Context. >>> >>> Public API to control the request context could be design in 2 different >>> ways: >>> 1) provide an interceptor to activate request context during the >>> intercepted method invocation >> >>This approach is also not always usable in some integration use cases >>where the request cannot be simply "wrapped in a single method call". >> >>For instance, in Quartz scheduler you can register a job listener with >>methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() - >>here the approach 2) would make sense. On the other hand, you could >>implement a JobFactory so that Job instances are beans (or at least >>instances obtained and injected from an InjectionTarget) and simply >>associate interceptor binding for its execute() method. >> >>> 2) provide a programmatic API accessible thru a bean (like the >>> Conversation bean) >>> >>> First solution is probably the easiest way for end user (to avoid not >>> ended context), but if we go for controlling Session Scope we won't be >>> able to provide a simple interceptor for it and will design something >>> like solution 2 for it. >>> >>> So the question is should we go for 1 or 2 or both (with a risk of >>> confusion) ? >> >>I think that both ways are legal and make sense. >> >>> >>> Thanks for your feedback >>> >>> 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. >>> >> > >_______________________________________________ >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 mkouba at redhat.com Thu Sep 29 07:14:29 2016 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 29 Sep 2016 13:14:29 +0200 Subject: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting In-Reply-To: <25208516.2526679.1475146750841@mail.yahoo.com> References: <8f7c5361-9966-b453-33d0-4a12d0b4cf1e@redhat.com> <25208516.2526679.1475146750841@mail.yahoo.com> Message-ID: <135d5c23-94c4-3999-596c-0afaa388ea3b@redhat.com> Dne 29.9.2016 v 12:59 Mark Struberg napsal(a): > Martins argument with Quartz is a good one. > > > Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches? That's a good point. But I think it should be ok to state that activate() is no-op if the request context is already active (and the same for interceptor). I.e. both the interceptor and the RequestContextControl bean should perform the check described below. > > So my vote is for the programmatic approach. > > > Oh and while we are at it: > If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code. > Of course it is possible by code like > > > try { > beanManager.getContext(RequestScoped.class); > // request context is active > } > > catch (ContextNotActiveException cnae) { > // request context is not active > // start it etc. > > } > > > But that seems a bit heavyweight, isn't? > > LieGrue, > strub > > > > On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand wrote: > > >> >> >> That's also my choice: >> We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature. >> >> >> A well written JavaDoc should prevent confusion between both approach. >> >> >> Antoine >> >> On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba wrote: >> >> >>> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a): >>>> Hi all, >>>> >>>> Just to sum up what was said during our Tuesday Hangout meeting. For >>>> those who were present feel free to correct or amend this. >>>> >>>> Controlling Request Context is something rather easy (because it's >>>> linked to one thread) while Session Context is far less obvious (used >>>> across multiple threads) so providing a generic solution to deal with >>>> their control seems quite complicated. >>>> That's why we decided to start addressing the Request Context control >>>> first and if we fell happy with that, continue the work on the Session >>>> Context. >>>> >>>> Public API to control the request context could be design in 2 different >>>> ways: >>>> 1) provide an interceptor to activate request context during the >>>> intercepted method invocation >>> >>> This approach is also not always usable in some integration use cases >>> where the request cannot be simply "wrapped in a single method call". >>> >>> For instance, in Quartz scheduler you can register a job listener with >>> methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() - >>> here the approach 2) would make sense. On the other hand, you could >>> implement a JobFactory so that Job instances are beans (or at least >>> instances obtained and injected from an InjectionTarget) and simply >>> associate interceptor binding for its execute() method. >>> >>>> 2) provide a programmatic API accessible thru a bean (like the >>>> Conversation bean) >>>> >>>> First solution is probably the easiest way for end user (to avoid not >>>> ended context), but if we go for controlling Session Scope we won't be >>>> able to provide a simple interceptor for it and will design something >>>> like solution 2 for it. >>>> >>>> So the question is should we go for 1 or 2 or both (with a risk of >>>> confusion) ? >>> >>> I think that both ways are legal and make sense. >>> >>>> >>>> Thanks for your feedback >>>> >>>> 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. >>>> >>> >> >> _______________________________________________ >> 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 EMIJIANG at uk.ibm.com Thu Sep 29 08:48:24 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Thu, 29 Sep 2016 13:48:24 +0100 Subject: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting In-Reply-To: <135d5c23-94c4-3999-596c-0afaa388ea3b@redhat.com> References: <8f7c5361-9966-b453-33d0-4a12d0b4cf1e@redhat.com> <25208516.2526679.1475146750841@mail.yahoo.com> <135d5c23-94c4-3999-596c-0afaa388ea3b@redhat.com> Message-ID: My choice is also: provide 2 solutions. I would expect most user cases can be solved by the solution 1. Only advanced users would use the solution 2. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Architect, Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: Mark Struberg , Antoine Sabot-Durand , cdi-dev Date: 29/09/2016 12:16 Subject: Re: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting Sent by: cdi-dev-bounces at lists.jboss.org Dne 29.9.2016 v 12:59 Mark Struberg napsal(a): > Martins argument with Quartz is a good one. > > > Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches? That's a good point. But I think it should be ok to state that activate() is no-op if the request context is already active (and the same for interceptor). I.e. both the interceptor and the RequestContextControl bean should perform the check described below. > > So my vote is for the programmatic approach. > > > Oh and while we are at it: > If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code. > Of course it is possible by code like > > > try { > beanManager.getContext(RequestScoped.class); > // request context is active > } > > catch (ContextNotActiveException cnae) { > // request context is not active > // start it etc. > > } > > > But that seems a bit heavyweight, isn't? > > LieGrue, > strub > > > > On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand wrote: > > >> >> >> That's also my choice: >> We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature. >> >> >> A well written JavaDoc should prevent confusion between both approach. >> >> >> Antoine >> >> On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba wrote: >> >> >>> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a): >>>> Hi all, >>>> >>>> Just to sum up what was said during our Tuesday Hangout meeting. For >>>> those who were present feel free to correct or amend this. >>>> >>>> Controlling Request Context is something rather easy (because it's >>>> linked to one thread) while Session Context is far less obvious (used >>>> across multiple threads) so providing a generic solution to deal with >>>> their control seems quite complicated. >>>> That's why we decided to start addressing the Request Context control >>>> first and if we fell happy with that, continue the work on the Session >>>> Context. >>>> >>>> Public API to control the request context could be design in 2 different >>>> ways: >>>> 1) provide an interceptor to activate request context during the >>>> intercepted method invocation >>> >>> This approach is also not always usable in some integration use cases >>> where the request cannot be simply "wrapped in a single method call". >>> >>> For instance, in Quartz scheduler you can register a job listener with >>> methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() - >>> here the approach 2) would make sense. On the other hand, you could >>> implement a JobFactory so that Job instances are beans (or at least >>> instances obtained and injected from an InjectionTarget) and simply >>> associate interceptor binding for its execute() method. >>> >>>> 2) provide a programmatic API accessible thru a bean (like the >>>> Conversation bean) >>>> >>>> First solution is probably the easiest way for end user (to avoid not >>>> ended context), but if we go for controlling Session Scope we won't be >>>> able to provide a simple interceptor for it and will design something >>>> like solution 2 for it. >>>> >>>> So the question is should we go for 1 or 2 or both (with a risk of >>>> confusion) ? >>> >>> I think that both ways are legal and make sense. >>> >>>> >>>> Thanks for your feedback >>>> >>>> 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. >>>> >>> >> >> _______________________________________________ >> 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160929/99204159/attachment.html From john.ament at spartasystems.com Thu Sep 29 08:56:13 2016 From: john.ament at spartasystems.com (John Ament) Date: Thu, 29 Sep 2016 12:56:13 +0000 Subject: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting In-Reply-To: References: <8f7c5361-9966-b453-33d0-4a12d0b4cf1e@redhat.com> <25208516.2526679.1475146750841@mail.yahoo.com> <135d5c23-94c4-3999-596c-0afaa388ea3b@redhat.com>, Message-ID: I was thinking about that as well. I agree with having both available, and both being able to do an activateIfNotActive() method (whether thats the activate() method or something else) ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Emily Jiang Sent: Thursday, September 29, 2016 8:48 AM To: Martin Kouba Cc: cdi-dev Subject: Re: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting My choice is also: provide 2 solutions. I would expect most user cases can be solved by the solution 1. Only advanced users would use the solution 2. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Architect, Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Martin Kouba To: Mark Struberg , Antoine Sabot-Durand , cdi-dev Date: 29/09/2016 12:16 Subject: Re: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting Sent by: cdi-dev-bounces at lists.jboss.org ________________________________ Dne 29.9.2016 v 12:59 Mark Struberg napsal(a): > Martins argument with Quartz is a good one. > > > Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches? That's a good point. But I think it should be ok to state that activate() is no-op if the request context is already active (and the same for interceptor). I.e. both the interceptor and the RequestContextControl bean should perform the check described below. > > So my vote is for the programmatic approach. > > > Oh and while we are at it: > If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code. > Of course it is possible by code like > > > try { > beanManager.getContext(RequestScoped.class); > // request context is active > } > > catch (ContextNotActiveException cnae) { > // request context is not active > // start it etc. > > } > > > But that seems a bit heavyweight, isn't? > > LieGrue, > strub > > > > On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand wrote: > > >> >> >> That's also my choice: >> We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature. >> >> >> A well written JavaDoc should prevent confusion between both approach. >> >> >> Antoine >> >> On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba wrote: >> >> >>> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a): >>>> Hi all, >>>> >>>> Just to sum up what was said during our Tuesday Hangout meeting. For >>>> those who were present feel free to correct or amend this. >>>> >>>> Controlling Request Context is something rather easy (because it's >>>> linked to one thread) while Session Context is far less obvious (used >>>> across multiple threads) so providing a generic solution to deal with >>>> their control seems quite complicated. >>>> That's why we decided to start addressing the Request Context control >>>> first and if we fell happy with that, continue the work on the Session >>>> Context. >>>> >>>> Public API to control the request context could be design in 2 different >>>> ways: >>>> 1) provide an interceptor to activate request context during the >>>> intercepted method invocation >>> >>> This approach is also not always usable in some integration use cases >>> where the request cannot be simply "wrapped in a single method call". >>> >>> For instance, in Quartz scheduler you can register a job listener with >>> methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() - >>> here the approach 2) would make sense. On the other hand, you could >>> implement a JobFactory so that Job instances are beans (or at least >>> instances obtained and injected from an InjectionTarget) and simply >>> associate interceptor binding for its execute() method. >>> >>>> 2) provide a programmatic API accessible thru a bean (like the >>>> Conversation bean) >>>> >>>> First solution is probably the easiest way for end user (to avoid not >>>> ended context), but if we go for controlling Session Scope we won't be >>>> able to provide a simple interceptor for it and will design something >>>> like solution 2 for it. >>>> >>>> So the question is should we go for 1 or 2 or both (with a risk of >>>> confusion) ? >>> >>> I think that both ways are legal and make sense. >>> >>>> >>>> Thanks for your feedback >>>> >>>> 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. >>>> >>> >> >> _______________________________________________ >> 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 Info Page - JBoss Developer lists.jboss.org List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives. Apache License, Version 2.0 www.apache.org Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160929/99409eb0/attachment-0001.html From issues at jboss.org Thu Sep 29 15:59:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Thu, 29 Sep 2016 15:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300577#comment-13300577 ] George Gastaldi commented on CDI-535: ------------------------------------- This is really interesting and useful. Can this make it to CDI 2.0 ? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 02:31:00 2016 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 30 Sep 2016 02:31:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300709#comment-13300709 ] Martin Kouba commented on CDI-535: ---------------------------------- One problem with {{javax.annotation.Priority}} is that its {{@Target}} is currently only TYPE (unfortunately Commons Annotations 1.3 MR only adds PARAMETER). So we will not be able to add priority to producer methods and fields. > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 03:32:01 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Fri, 30 Sep 2016 03:32:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300750#comment-13300750 ] George Gastaldi commented on CDI-535: ------------------------------------- Good point. Can we enhance the Priority annotation or would that take ages to be accepted? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 03:34:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Fri, 30 Sep 2016 03:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300756#comment-13300756 ] George Gastaldi commented on CDI-535: ------------------------------------- Or we could introduce this feature for what @Priority has for now and in a later spec update support producer methods? > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 03:38:00 2016 From: issues at jboss.org (George Gastaldi (JIRA)) Date: Fri, 30 Sep 2016 03:38:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-535) cdi instance injection ordering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300762#comment-13300762 ] George Gastaldi commented on CDI-535: ------------------------------------- Or add a priority method to @Produces? I prefer the @Priority annotation tbh > cdi instance injection ordering > ------------------------------- > > Key: CDI-535 > URL: https://issues.jboss.org/browse/CDI-535 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 (discussion) > Reporter: Ochieng Marembo > Priority: Optional > > We should allow ordering of bean instance injection using the ```Instance``` when an instance injection is used. > h3. Use case: > Developer always define a kind of chain of processor beans, which may need to run in specific order. > h3. Current scenario: > Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following: > #1 > {code} > private Iterable myBeans; > @Inject > void injectBeans(@Any Instance myBeans) { > //the create order does some kind of ordering on the beans. > this.myBeans = createOrder(myBeans); > } > {code} > #2 > This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call. > {code} > @Any > @Inject > private Instance myBeans; > public void doSomething() { > Iterable orderedbeans = createOrder(myBeans.select(someQualifier)); > } > {code} > h3. Our Proposal > We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code} > {code} > public interface MyBeanInterface {} > @MyQualifier > @Priority(0) > public class MyFirstBean implements MyBeanInterface{ > } > @MyQualifier > @Priority(2) > public class MySecondBean implements MyBeanInterface{ > } > @ApplicationScoped > public class MyBeanProcessor { > //We expect that this injected instances shall be in order based on the @Priority annotation > @Any > @Inject > private Instance myBeans; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)